Funds network and method

ABSTRACT

In a method of providing funds to a monetary repository, information is received identifying a payee and request by the payee to convert a negotiable instrument made to the payee to funds. In response to the information, confirmation is received whether to convert the negotiable instrument to funds. An image of the endorsed negotiable instrument is received. If a determination is made to convert the negotiable instrument to funds, an amount of funds corresponding to a value of the negotiable instrument is directed to a repository.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/767,624, filed Feb. 14, 2013, entitled “Funds Network and Method,”which claims the benefit of U.S. Provisional Patent Application Ser. No.61/599,371, filed Feb. 15, 2012, entitled “Funds Network and Method.”

BACKGROUND OF THE INVENTION

Services have existed for converting negotiable instruments into goodfunds. As used herein, “good funds” refers to funds that are transferredto a recipient without risk on the recipient's part that the funds willbe reversed. Currency is a traditional form of good funds whentransferred without underlying contractual obligations, but good fundsalso encompass electronic and other non-physical currency valuetransferred without recourse against the recipient.

A person in possession of a negotiable instrument may need to directfunds to accounts that are associated with the person, such as prepaidcard accounts, invoice accounts, or direct deposit bank accounts, orother functions such as money transfers. Depending on the desireddestination, the account manager may accept funds in various forms. Forinstance, a local public utility might accept checks drawn on directdeposit bank accounts. Managers of pre-paid services accounts generallydo not accept checks but may accept funds delivered by direct depositpayroll files to their bank accounts. Where the person does not have adeposit bank account or, in the case of prepaid services, a payrolldirect deposit relationship, however, the managers generally require asource of good funds in order to finalize receipt of the funds such thatthe funds are available for the intended purpose. A prepaid card issuer,for example, requires good funds be received into an account in order tomake the funds available for withdrawal through use of a prepaid cardassociated with the account.

A person in possession of a negotiable instrument such as a check (forease of example, the discussion herein refers to checks, but this is forpurposes of explanation only, and it should be understood that thepresent discussion can encompass other types of negotiable instruments)may acquire good funds through a check cashing entity that makes aunilateral decision, in some cases based on its own criteria and uponinformation it may acquire from the instrument holder or a check riskmanagement service, whether to cash the check. Alternatively, the checkcashing entity may have a relationship with a check guarantor service,under which the check cashing entity provides certain predeterminedinformation to the check guarantor, and in response to which the checkguarantor approves or denies the check. If the check cashing entitydecides to cash the check, alone or in conjunction with a check riskmanagement service or guarantor, the check cashing entity may providecurrency to the instrument holder, less a fee, and the holder endorsesthe check over to the check cashing entity.

If the check cashing entity cashes the check and provides currency tothe check presenter, the presenter may then present currency to managersof respective accounts to which the presenter desires to direct funds.Alternatively, some check cashing entities provide an additional serviceof directing good funds to such account managers.

For example, assume a consumer presents a retailer with a check made tothe consumer and that the retailer makes a determination, either locallyor with the assistance of a check risk management service or guarantor,to cash the check. Following that decision, or in some instances priorto check verification, the consumer endorses the check over to theretailer and provides instructions to the retailer regarding an accountto which the consumer wishes to direct funds.

The retailer then directs good funds in the amount of the check or someportion thereof, less fees charged to the consumer, to the desiredaccount, for example via a load network. The load network is an entitythat maintains a server system that can be accessed remotely, typicallyover the Internet or through a link to a retailer's point of salesystem. The load network maintains contractual agreements with managersof prepaid debit card accounts that allow the load network to directfunds to the prepaid accounts. The load network also maintainscontractual agreements with check cashing entities (e.g. the retailer inthis example) under which the load network has the ability to transferfunds involved in a transaction from designated deposit accounts ownedby these entities. Accordingly, when the retailer receives and decidesto cash the consumer's check, and when the consumer providesinstructions to the retailer directing the retailer to direct checkproceeds to a reloadable prepaid card, the retailer accesses the loadnetwork server and provides an instruction to the load network totransfer an amount of funds equal to the check value, less fees chargedto the consumer, to an account associated with the card issuer. Inresponse, the load network transfers the requested amount of funds fromthe retailer's deposit account designated in the agreement between theretailer and the load network to the requested prepaid card account. Theload network may also transfer to itself a portion of the fee, againpursuant to the agreement between the retailer and the load network.

Through the load network, the retailer provides funds to the prepaidcard account manager without recourse either to the load network or theaccount manager in the event the check returns. For example, if thecheck is returned for insufficient funds or other reasons, the retailerdoes not reverse the transaction back to the load network and/or thecard issuer. In some instances, there may be an agreement between theretailer and the card issuer under which funds may be reversed in orderto facilitate collection on the check, but such agreement does notrelieve the retailer of ultimate responsibility for the funds if thecheck is not collected. The funds transfer remains in place, andliability thus rests with the retailer. If the retailer contracts with acheck guarantor, the retailer may mitigate its risk by allocating someor all of the retailer's risk to the check guarantor, but regardless,liability rests with the retailer from the perspective of the loadnetwork and the card issuer.

In this system, the load network derives revenue (i.e. a fee assessedfrom the fee retained by the retailer from the check proceeds, asdescribed above) from the transactions independently of the card issuerand/or the entity managing the card accounts. The prepaid issuertypically pays for membership in the load network but isn't charged aper-transaction fee for the receipt of good funds. The prepaid cardissuer retains its fee from the load amount received from the loadnetwork. This fee arises from the agreement between the card issuer andthe consumer and is independent of the relationship between the cardissuer and the load network. In some cases, when the retailer decides tocash a check and then load the proceeds onto a prepaid card through aload network, the retailer waives all or some part of either theretailer fee to cash the check or the load network fee, but this isindependent of the card issuer.

Check guarantors may have consumer-accessible outlets (e.g. at retail orstand-alone facilities) at which a consumer may present a check forcashing.

Referring to an exemplary prior art transaction 10 illustrated in FIG.1, a consumer 12 has a plurality of checks 14 in a physical wallet 16.The checks are made to consumer 12 as the payee. Consumer 12 presentsthe checks to a check cashing service provider 18, which could be aretailer or a stand-alone check cashing entity. If the consumer has anexisting deposit account and credit relationship with a bank, theconsumer could simply cash the check through the deposit account bank.Even if the consumer has such a banking relationship, however, theconsumer may not have sufficient knowledge about the check maker to haveconfidence in the funds. If the consumer cashes the check at the directdeposit bank, the bank will generally charge the check amount back tothe consumer in the event the check is returned. Check cashing serviceprovider 18 may have recourse against the consumer but, as a practicalmatter, may not be sure of its ability to recover the check funds. Thus,as noted above, the check cashing service provider typically accepts therisk of the check being returned and therefore charges a fee to theconsumer for cashing the checks.

Assuming consumer 12 presents the check to check cashing serviceprovider 18, an operator at the facility may acquire identificationinformation from the consumer, e.g. orally and/or through inspection ofidentification documentation such as a driver's license, and query acheck guarantor or risk management service (e.g. through a local networkor an Internet connection) regarding whether the consumer is enrolled inits system. If, after receiving the consumer information, the checkguarantor or risk management service does not have a record for theconsumer in its system, the check guarantor/service responds to thecheck cashing service provider with a message that the consumer is notenrolled in the system. The operator then requests further informationfrom the consumer and forwards the consumer information to the checkguarantor/service. Assuming the consumer is enrolled, or becomesenrolled, the operator may acquire information about the check, forexample the payee, the maker, the maker's bank, the amount, the type ofcheck, and the date. The operator may acquire check information throughvisual inspection of the check and/or by scanning the check to read themagnetic ink character recognition (MICR) data and/or for remoteinspection. Check validation may occur locally at the check cashingservice provider but may also be made in conjunction with the remotecheck risk management service and/or guarantor. A risk managementservice advises a check cashing entity about risk, whereas a guarantoraccepts the risk of cashing a check. Assuming validation via a remoteentity, the operator at check cashing service 18 may communicate (e.g.through a local network or an Internet connection) the check informationto the check guarantor or risk management service.

The check guarantor/service assesses a risk in cashing the check, basedon the consumer information, the check information, databaseinformation, and potentially other factors. Based on the riskassessment, the check guarantor/service communicates (through anelectronic message and/or by voice communication) a decision to theoperator at the check cashing facility whether to cash the check. If thedecision is that the check should not be cashed, the transaction ends.If the decision is to cash the check, check-cashing service provider 18provides cash to the consumer, ending the transaction.

While check cashing services traditionally have been provided bycompanies for which check cashing is the company's only business, morerecently retailers, banks and other businesses choose to offer thisservice.

At 13, after obtaining cash for a check, the consumer may utilize thecash to acquire prepaid services or otherwise allocate the cash. In someinstances, this may occur as a net transaction from the consumer'sperspective, without the consumer ever receiving physical currency.Nonetheless, there are two separate transactions (i.e. (a) check cashingand (b) funds allocation, where the second transaction involves theaccount manager, but the first (i.e. check cashing) occurs independentlyof the account manager).

For example, the consumer may allocate the funds to a reloadablepre-paid card, at 20. Prepaid cards, of various types, have been knownfor many years, generally beginning with closed loop gift cards andevolving into today's general purpose reloadable (“GPR”) cards. Prepaidcards can be generally classified as reloadable or single load cards.Single load cards are static. Once purchased and assigned a value, theycannot be reloaded with additional funds. In contrast, re-loadable cardscan be replenished with funds after their initial purchase. Single loadcards can be purchased anonymously. As there is no need to identify thepurchaser, the single load card itself carries no information about thecustomer/purchaser. In contrast, a reloadable card is, in essence,backed by a bank account and is therefore associated with card owneridentification information. The bank is responsible for completingidentity verification in compliance with a written customeridentification policy (“CIP”).

Although a reloadable card is generally issued by a bank, the cards andtheir associated accounts are generally managed by a separate entity,and thus the term “account manager” is used herein. Thus, with respectto a reloadable card, the term “manager” should be understood to referto the bank and/or a separate managing entity, if applicable.

If the consumer wishes to load the check proceeds to a reloadable card,but does not yet have a card, the consumer may acquire a card from avendor or directly from a reloadable card account manager, for examplevia the Internet or retail outlets. In such a transaction, the consumerenrolls with the card account manager by providing information to set upan account in the card account manager's system.

Assuming the consumer has a card, the consumer provides that portion ofthe now-acquired cash the consumer wishes to allocate to the prepaidcard account to a vendor having a relationship with either the cardmanager or a load network. Through such relationships, the vender loads,in essence deposits, the proceeds onto the card, i.e. into an accountassociated with the card, at the account manager. The consumer feeassociated with this load is typically deducted from the proceeds andretained by the vendor and the load network.

For example, assume a consumer purchases or reloads a card at a retailfacility at which the consumer cashes a check. If the consumer is notenrolled in the card manager's system, the consumer may provideenrollment information at the retailer's customer service desk, whichcommunicates with the card manager over a network connection to enrollthe customer. Upon enrolling, or if the consumer has an existing card,the customer may proceed to a retailer checkout station. A checkoutclerk swipes the card through a magnetic card reader at the clerk'spoint of sale device. The point-of-sale device reads the card, acquirescard information from the card, and communicates that information to aload network. Upon being informed by the consumer of the amount theconsumer wishes to load to the card, the clerk enters the requestedamount (plus a fee) through the point-of-sale device keyboard andaccepts the cash proceeds from the consumer. The point-of-sale deviceelectronically notifies the load network that the check proceeds havebeen accepted for allocation to the card manager account associated withthe card (via the card number read by the point-of-sale device).Pursuant to an agreement between the load network and the retailer, theload network transfers the requested amount from an account owned by theretailer to the card manager account. The load network transfers aportion of the fee to the load network, with the remainder of the feeremaining in the retailer's account.

Consumer 12 may also allocate some or all of the check proceeds to amoney transfer at 22. As should be understood, a money transfer is aremitter-to-recipient service maintained by a service provider, forexample WESTERN UNION. The consumer manually presents the desired fundsto the money transfer service provider and instructs the serviceprovider to allocate the designated amount of funds for transfer to adesignated recipient. Consumer 12 may also allocate some or all of thecheck proceeds to an automatic bill paying account, such as provided byservices such as CHECKFREE PAY, at 24, purchase a money order from amoney order provider at 26, and/or pay for a prepaid telephone card at28. At any of these steps, the manager (i.e. WESTERN UNION, CHECKFREEPAY, the money order provider, or the telephone card provider in theseexamples) may charge a fee to the consumer. A retailer may provideaccess to such managers, such that the consumer may allocate funds tothe repository managers at the retail check out system, as individualtransactions.

Systems and methods are known for capturing an image of a check andsubmitting the check to a financial institution for deposit to anaccount owned by the check payee. For instance, a bank may provideapplications operable on a depositor's mobile telephone, by which thedepositor may acquire images of checks and transmit the images to thedepositor's bank. The bank, in turn, deposits the check proceeds intothe depositor's account, sometimes making the funds availableimmediately but more generally at some time over the following one tofive days or according to the bank's availability schedule.

SUMMARY OF THE INVENTION

One or more embodiments of the present invention may recognize andaddress disadvantages of prior art constructions and methods asdescribed above.

In one embodiment of a method of converting to funds a negotiableinstrument made to a payee, a computerized system is provided that isaccessible to remote parties through a computer network and that iscontrolled by an entity. At the computerized system, via a first networkand from a device remote from the computerized system, information isreceived that identifies a payee and indicates a request from the payeeto convert a negotiable instrument made to the payee to funds. Also atthe computerized system from the remote device through the firstnetwork, an image of the negotiable instrument is received. An image ofthe negotiable instrument is presented to an operator from thecomputerized system via a display. At the computerized system from theoperator via an interface, information is received that classifies thenegotiable instrument to a type of instrument maker among apredetermined plurality of types of negotiable instrument makers. A feeis determined for converting the negotiable instrument to funds based atleast in part on the type of instrument maker. At the remote device viaa user interface, an option is presented to the payee to accept the fee.At the computerized system from the remote device via the first network,information is received from the payee indicating a response to theoption. Depending at least in part upon whether the information from thepayee indicates the payee accepts the fee, the negotiable instrument isprocessed, at the computerized system, for conversion to funds. Throughthe computer network, settlement of the negotiable instrument isdirected.

In another embodiment, a method of converting to funds a negotiableinstrument made to a payee includes providing a computerized system thatis accessible to remote parties through a computer network and that iscontrolled by an entity. At the computerized system via a first networkfrom a device remote from the computerized system, information isreceived that identifies a payee and indicates a request from the payeethat a negotiable instrument made to the payee be approved forconversion to funds. At the computerized system, a plurality ofprotocols is provided for converting negotiable instrument to funds.Each protocol of the plurality of protocols bases conversion of anegotiable instrument to funds at least in part on a current of apredetermined triggering condition that is different from the triggeringcondition of each other protocol. At the remote device via a userinterface, an option is presented to the payee to select a protocol ofthe plurality of protocols for conversion of the negotiable instrumentto funds. At the computerized system from the remote device via thenetwork, instructions are received from the payee indicating a saidprotocol selected by the payee. At the computerized system, thenegotiable instrument is processed for conversion to funds uponoccurrence of the predetermined triggering condition corresponding tothe selected protocol. Settlement of the negotiable instrument isdirected through the computer network.

In a still further embodiment, a method of converting to funds anegotiable instrument made to a payee includes providing a firstcomputerized system that is accessible to remote parties through acomputer network and that is controlled by an entity. At the firstcomputerized system via a first network from a user interface at adevice remote from the computerized system, information is receivedidentifying a payee and indicating a request from the payee to convert anegotiable instrument made to the payee to funds. The user interface isin communication with the first computerized system and with a secondcomputerized system controlled by an entity that manages at least one ofreloadable debit card transactions and reloadable debit card accounts.At the first computerized system from the remote device through thefirst network, an image of the negotiable instrument is received. A feeis determined for converting the negotiable instrument to funds inresponse to the first computerized system and the second computerizedsystem. At the remote device via user interface, an option is presentedto the payee to accept the fee. At the computerized system from theremote device via the first network, information is received from thepayee indicating a response to the option. Depending at least in partupon whether the information from the payee indicates the payee acceptsthe fee, the negotiable instrument is processed at the computerizedsystem for conversion to funds directed to a reloadable debit cardaccount via the second computerized system. Settlement of the negotiableinstrument is directed through the first computer network.

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate one or more embodiments of thepresent invention.

BRIEF DESCRIPTION OF THE DRAWINGS

A full and enabling disclosure of the present invention, including thebest mode thereof directed to one of ordinary skill in the art, is setforth in the specification, which makes reference to the appendedfigures, in which:

FIG. 1 is a schematic view of a prior art check cashing transaction;

FIG. 2 is a schematic view of a transaction made through an embodimentof the system and method according to the present invention;

FIGS. 3A-3G are a partial flow diagram view of a method according to anembodiment of the present invention;

FIG. 4 is a schematic view of a system according to an embodiment of thepresent invention;

FIG. 5 is a flow diagram view of a method of enrolling a customer intothe funds network according to an embodiment of the present invention;

FIG. 6 is a flow diagram view of a method of enrolling a customer into afunds network according to another embodiment of the present invention;

FIGS. 7A-7B are a flow diagram view of a method of enrolling a customerinto mobile deposits according to another embodiment of the presentinvention;

FIGS. 8A-12B illustrate flow diagram views of methods of processing anegotiable instrument according to another embodiment of the presentinvention;

FIGS. 13A-13B are a flow diagram view of a method of depositing fundsaccording to an embodiment of the present invention; and

FIG. 14 is a flow diagram view of a method of processing returned checksaccording to an embodiment of the present invention.

Repeat use of reference characters in the present specification anddrawings is intended to represent same or analogous features or elementsof the invention.

DETAILED DESCRIPTION

Reference will now be made in detail to presently preferred embodimentsof the invention, one or more examples of which are illustrated in theaccompanying drawings. Each example is provided by way of explanation ofthe invention, not limitation of the invention. In fact, it will beapparent to those skilled in the art that modifications and variationscan be made in the present invention without departing from the scopeand spirit thereof. For instance, features illustrated or described aspart of one embodiment may be used on another embodiment to yield astill further embodiment. Thus, it is intended that the presentinvention covers such modifications and variations as come within thescope of the appended claims and their equivalents.

One or more embodiments of the invention described herein areimplemented at least partially as and/or using computer programs for usewith a computer system, such as, for example, the network environmentshown in FIG. 4 and described herein. The programs define functions ofthese embodiments (including one or more methods described herein) andcan be contained on a variety of computer-readable media, for example,information stored on non-writable storage media (for example, read-onlymemory devices within a computer (for example server 200) such as CD-ROMdiscs readable by a CD-ROM drive), alterable information stored onwritable storage media, and information conveyed to a computer by acommunications medium, such as through a computer or telephone network,including wireless communications. The latter embodiment specificallyincludes information and functions downloaded from the internet andother networks. Such computer-readable media, when carryingcomputer-readable instructions that direct the functions of one or moreembodiments of the present invention, represent embodiments of thepresent invention.

In general, routines executed to implement embodiments of the presentinvention described herein may be part of an operating system for aspecific application, component, program, module, object, or sequence ofinstructions. The computer program typically is comprised of a multitudeof instructions that may be translated by a computer into amachine-readable format and hence executable instructions. Also,programs are comprised of variables and data structures that eitherreside locally to the computer program or are found in memory or onstorage devices. In addition, various programs effecting methodsdescribed herein may be identified based upon the application for whichthey are implemented in a specific embodiment. However, it should beappreciated that the invention should not be limited to use solely inany specific application or function identified and/or implied herein.

FIG. 4 illustrates a network environment. Client computer systems (e.g.206, 208, 94 and 212) as described herein include interfaces that enablenetwork communications with other systems (e.g. server 200) over thenetwork. The network may be comprised of remote network connections,among geographically distributed systems, including network connectionsover the Internet. Each client computer system generally includes acentral processing unit connected by a bus to memory and storage (notshown). Each client computer system typically runs an operating systemconfigured to manage interaction between computer hardware andhigher-level software applications running on the client system.

Server 200 may include hardware components similar to those used by theclient computer systems. Accordingly, server 200 generally includes aCPU, memory, and storage devices coupled by a bus. The server also runsan operating system and may include a runtime component and a databasemanagement system. In response to functions performed by an applicationrunning on the server, the runtime component may receive queries inresponse to which the runtime component generates Structured QueryLanguage (SQL) queries that it provides to the database managementsystem for execution in conjunction with database 202.

The network environment illustrated in FIG. 4 is, however, merely anexample of one computing environment. Embodiments of the presentinvention may be implemented using other environments, regardlesswhether the computer systems are complex multi-user computer systems,such as a cluster of individual computers connected by a high-speednetwork, single-user workstations, or network appliances lackingnon-volatile storage. Further, the software applications describedherein may be implemented using computer software applications executedon existing computer systems that are not limited to any currentlyexisting computing environment or programming language, and may beadapted to take advantage of new computing systems as they becomeavailable.

In certain embodiments as described herein, users of computer systemsinteract with client computer systems and/or server 200 using one ormore graphical user interfaces (GUI). GUI content may comprise hypertextmarkup language (HTML) documents (i.e., web-pages) rendered on thecomputer system using a web browser. In such an embodiment, server 200may include a hypertext transfer protocol secure (HTTPS) serverconfigured to respond to HTTPS requests from client systems and transmitHTML documents to client systems. The web-pages themselves may be staticdocuments stored on server 200 or generated dynamically using theapplication server interacting with the web-server to service HTTPSrequests. Alternatively, client applications may comprise a database, orquery application program running on the client system. The web-browserand application may be configured to allow a user to compose an abstractquery, and to submit the query to a runtime component for processing.

FIG. 4 illustrates a system according to an embodiment of the presentinvention. Although the embodiment is described with respect to fundsderived from a check, it should be understood that funds may be derivedfrom other negotiable instruments, such as time drafts or promissorynotes, within the scope of systems and methods encompassed by thepresent invention. A funds network 38 is embodied by one or morecomputer servers 200 and databases 202. Although a single server isindicated for computer server 200, and a single database for database202, it should be understood that the network may be comprised ofmultiple servers and databases, whether located locally and networkedthrough a local area network or remotely through a wide area network oran Internet connection. Thus, the single representations at 200 and 202are provided for purposes of illustration only and should be understoodto represent such other configurations. Moreover, particularly where aconsumer interacts with the funds network through an automated tellermachine or other automated device, such as kiosks 208(1)-208(N), thefunds network may be considered to include such automated devices.

A plurality of check cashing entities, represented at 204, may comprisestand-alone check cashing facilities 206(1)-206(N) and/or a plurality ofunmanned automated teller machines or kiosks 208(1)-208(N), all incommunication with server 200 through remote connections, for examplethrough the Internet 210. In general, the check cashing entities areremote from the funds network in that the check cashing entities and thefunds network do not have common control over their respective computersystems and databases. In general, but not necessarily, the checkcashing entities and the funds network do not communicate over a common,dedicated communications wired or wireless link, but rather communicateover a communication network or system that is independent of both thecheck cashing entity and the funds network. Further, some or allcommunications between and among remote parties and entities asdescribed herein are, in at least one embodiment, made over securecommunication channels, e.g. employing encryption techniques. Encryptionmethods and systems should be well understood, are not part of thepresent invention in-and-of themselves, and are therefore not discussedin further detail herein.

Stand-alone check cashing facilities 206 may be respectively operated byan on-site human operator who communicates with the funds networkthrough a computer system at the stand-alone facility via theindependent communication network. The check-cashing facility may beoperated by the owner of, and as part of, funds network 38 or by aretailer or other entity unrelated to the funds network. Each facility206 comprises a computer with a data entry or capture device or devices,for example a keyboard, card reader, and check scanner through which theoperator communicates with funds network 38 and server 200 to provideinformation relevant to the transaction, as described in more detailbelow. Remote, customer-operated devices 208, such as automated tellermachines, kiosks, or mobile telephones, tablets or other devices, arenot necessarily operated by the check-cashing entity but may haveinterface software through which the person presenting the instrumentcommunicates with the funds network and/or the check-cashing entity orother entity, such as a reloadable debit card manager. Kiosks and ATMs208 may have a similar configuration to the computer system at 206, withthe same data entry or capture devices. Where a mobile device is used,via an application loaded on the mobile device, data may be keyed intothe device, and a check image may be captured by a camera on the phone.Computer software resident on the terminals or in a cloud configurationeffect the transactions described in more detail below. Where fundsnetwork 38 owns and/or operates the check-cashing entity, it performsboth the check-cashing entity and funds network roles as describedherein, and it should be understood that operation as the funds networkdoes not preclude the network's operation also as a check-cashing entityor other component of the transaction, such as a check guarantor. Ingeneral, the check cashing entity is the acquirer of the negotiableinstrument in that the check cashing entity acquires possession of thenegotiable instrument from the payee (or a transferee from the payee)for purposes of converting the negotiable instrument to funds, through asettlement system. From the payee's perspective, the acquirer is theimmediate intermediary between the payee and the settlement process.

Terminals and/or servers located at check cashing guarantors94(1)-94(N), and a plurality of prepaid card issuers/managers212(1)-212(N), communicate with funds provider server 200 throughrespective Internet connections. As should be understood in this art,card issuers are generally banks, but the accounts associated with cardsissued by the banks are controlled by other entities, the managers, thatmaintain the accounts and manage transactions relating to the cards. Itshould also be understood that funds recipients/repositories may includeentities other than card issuers/managers, and thus additional blocks212 could be shown in FIG. 4 to represent such other entities. Thus, thedescription of card issuers/managers is solely for purposes ofexplanation. Each entity in FIG. 4 maintains its own computer systems,which may comprise workstations, servers and/or other computing devices,databases and local networks, independently of the funds network.

Also referring to FIG. 2, a consumer 12 may present one or more checks14 to funds network 38 via a check cashing entity at 206 or 208 toobtain funds. The consumer is the check payee (who may be a transferee),and the check cashing entity takes possession of the one or more paperchecks from the consumer, who requests the check be converted to funds.The check cashing entity forwards to the funds network information thatidentifies the consumer and the request. Funds network 38 provides fundsto a monetary repository as requested by consumer 12, in this example aprepaid card provider who then provides funds to consumer 12 after thefunds network validates the check in conjunction with a check cashingguarantor. In one embodiment, and as described in more detail below,funds network 38 validates the check through a check guarantor selectedfrom a plurality of available guarantors according to a predeterminedalgorithm, and may access a greater amount of relevant data in makingthe check verification than is practically available to any singleguarantor other than the funds network.

As described in more detail below, consumer 12 may present a check tofunds network 38 directly (for example through a kiosk 208 or a fundsnetwork-operated check cashing service location 206) or indirectly (forexample through a retailer-operated service location 206). Assuming thefunds network decides to convert the check to value, funds network 38provides good funds to the prepaid card provider, who then makes thefunds available to the consumer through a card. Generally, the consumerendorses the check to the funds network rather than to the check-cashingentity, and the funds network presents the check through a paymentprocessing system for payment with recourse to the funds network. Thus,funds network 38 provides good funds to repository managers, for exampleprepaid access providers, without the check-cashing entity involved inthe settlement loop and without the check-cashing entity, and possiblywithout the repository manager (where the funds network and therepository manager are separate entities), assuming liability for thosefunds in the event of returned checks.

Also as described in more detail below, one embodiment of funds network38 may have access to multiple check guarantors and offers an auction tothe guarantors to provide check guarantees. Because the funds networkhandles and records check transactions from multiple guarantors, fundsnetwork 38 may provide a greater breadth of transactional data to agiven check guarantor in a given check-cashing transaction than theguarantor would be able to access if the guarantor were handling thetransaction independently of the funds network, thereby enhancing thelikelihood the check cashing verification decision is correct. In anembodiment in which the funds network aggregates a plurality ofguarantors, the funds network 38 may provide a higher probability ofapproval and/or a lower cost approval by broadening the spectrum ofguarantors on any given guarantee request.

In a still further embodiment, funds network 38 may provide anelectronic wallet (e-wallet) into which a consumer can direct proceedsfrom a check and from which the consumer can allocate funds intorepositories such prepaid access accounts or service accounts (e.g. forpaying invoices to service providers).

Funds network 38 maintains one or more deposit bank accounts in one ormore banks or other financial institutions. The funds network maintainsa customer record in a table of database 202 of each consumer who hasenrolled with the funds network. The customer record indicates whetherthe consumer has registered with the funds network for an e-wallet. Foreach such consumer, the database customer record indicates the amount offunds allocated to that consumer's e-wallet, and the funds networkmaintains a corresponding amount in its bank account(s). The consumerand funds network 38 enter an agreement governing terms and conditionsunder which funds network 38 maintains the consumer's funds in thee-wallet account and under which the consumer may draw from thataccount. Alternatively, an entity separate from the load network may ownthe e-wallet account and operate as described herein based on acontractual arrangement with the load network. When the consumer loads acheck through the funds network, the system may automatically direct theproceeds to an e-wallet, if the consumer has an e-wallet account, or thesystem may provide a query option through which the consumer can requestthat the proceeds be deposited in the consumer's e-wallet. In thatevent, when funds network 38 obtains a guarantee on the check, the fundsnetwork deposits the proceeds into the funds network e-wallet associatedbank account and credits the consumer's record in database 202accordingly.

More specifically, assume that the consumer presents a load request tothe funds network by swiping a pre-paid card at a kiosk 208 or computingdevice 206 such that the kiosk or computing device submits the cardnumber to server 200 through an Internet or other network connection.Prior to verifying the check for loading as described above, the fundsnetwork checks the card number against a table in database 202 thatcontains customer records. These customer records include all cardnumbers associated with consumers enrolled in the funds network and alsoindicate whether each consumer has registered for an e-wallet. If server200 determines from the card number received as the load request thatthe card number is associated with an e-wallet, server 200 identifiesthe consumer associated with the card in the database table and proceedsthrough the check verification and cashing procedure described in moredetail below. If check-cashing concludes successfully, the funds networkloads check proceeds to the consumer's e-wallet account as indicated at42 in FIG. 2, or possibly another account the consumer may establish inthe process.

If the card number is not associated in database 202 with an e-walletaccount, server 200 acquires the bank identification number (BIN) fromthe card number and checks a table in database 202 to determine whetherthe BIN is associated with a card issuer who has enrolled with the fundsnetwork. Alternatively, as the table may be configured to correlate cardissuers with the entire card number, so that the table lists all cardsof that issuer involved in transactions, the system could locate thecustomer with the full card number. In either arrangement, server 200determines whether the card has been issued by an enrolled card issuer.Enrollment represents a prior contractual arrangement between fundsnetwork 38 and each participating card issuer that allows funds network38 to automatically access the card issuer's computerized system andprovides for the settlement of funds with the card issuer. If the cardis associated with an enrolled card issuer, the funds network proceedsthrough the check verification process as described in detail below. Ifthe check verification is successful, funds network 38 loads checkproceeds to the card, as indicated at 20 in FIG. 2.

Alternatively, funds network 38 may offer the consumer a choice, througha user interface, to allocate proceeds of cashed checks to a prepaidcard account (or other prepaid access account) or an e-wallet. Forexample, prior to verifying the check for loading as described above,the consumer may be prompted (by an automatic screen display driven by auser interface or manually by an operator) to select whether to applycheck proceeds into e-wallet 42 or directly onto a prepaid card or otherprepaid access account at 20. If the consumer elects to deposit funds ina prepaid card or other prepaid account, the consumer may select thatoption through the user interface at a kiosk 208 or may inform theservice provider operator who, in turn, communicates the choice to fundsnetwork server 200 via the operator's terminal. If the consumer selectsthe e-wallet, the funds network acquires the consumer's prepaid cardnumber and locates the consumer's e-wallet account, as described above.If the consumer selects the prepaid card, the system acquires the cardnumber and determines whether the card issuer is enrolled in the fundsnetwork, as discussed above.

Whether selection between the prepaid card account and e-wallet isautomatic or through an interface, and as described in more detailbelow, the funds network then proceeds to acquire data and verify thecheck. Assuming the check is verified, the funds network allocates checkproceeds to the card or the e-wallet.

The consumer may later wish to allocate funds from the e-wallet tovarious repositories. To do so, the consumer accesses server 200 via ausername/password log-in procedure (or by swiping a card issued by aprepaid card provider enrolled in the funds network, biometric data orother security mechanism) on a funds network kiosk 208 or a consumermobile or other computing device 206 that connects directly with server200 through an Internet connection by requesting a uniform resourcelocator (URL) associated with server 200 through an Internet web browserthat is located on the consumer's computing device. The consumer mayaccess the funds network server in various ways, for example aWAP-enabled device. In response to access by consumer 12, a computerprogram executed by server 200 presents the consumer with the userinterface on the consumer's computing device, and the user interfaceprovides the consumer the choice between executing a load transactionand accessing the consumer's e-wallet account. Alternatively, if theconsumer is already in communication with server 200 through such aconnection for conducting a load transaction as described herein, theconsumer may simply select an e-wallet allocation option instead of orafter the funds load function, thereby changing to allocation mode. Oncein e-wallet allocation mode, server 200 presents the consumer with ascreen identifying the consumer's e-wallet balance and prompting theconsumer for instructions regarding allocation of e-wallet funds. Theuser interface presents a list of prepaid cards associated with theconsumer database 202, along with a list of other monetary repositoryproviders enrolled in the funds network and, possibly, associated withthe consumer. Through the user interface, consumer presents aninstruction to server 200 to allocate funds from the consumer's e-walletaccount to the consumer's desired repository.

Assume, for example, that the consumer selects a prepaid card 20. Theuser interface then prompts the consumer to enter a desired amount toallocate from the e-wallet to the card. After the funds network receivesthe instructions, it effects a funds transfer of the requested amount tothe account manager associated with the card, and the card accountmanager credits the consumer's prepaid account by that amount, less anyfees assessed by the card issuer. The funds network may also debit a feefor the funds network as disclosed in the terms and conditions of anagreement between the funds network and the consumer. The networktransfers the moneys owed to the prepaid card issuer at an agreed uponsettlement date in the future via electronic transfer.

Through the user interface, consumer 12 may provide instructions toserver 200 to allocate some or all of the funds in the consumer'se-wallet to other monetary repositories controlled by managers that havecontracted with the funds network to allow the funds network to loadfunds to their accounts, and the consumer may select such otherrepositories through the server 200 user interface. For example, theuser interface may provide the consumer the option to allocate fundsfrom e-wallet 42 to a money transfer at 22. After selection of thisoption through the user interface, the user interface prompts consumer12 to identify the money transfer service provider (e.g. WESTERN UNION),the recipient, and the amount of the proceeds to be directed to themoney transfer account. Funds network 38 has a preexisting contractualrelationship with the service provider under which the funds networkfeeds the service provider's application program interface (API) to theconsumer's computing device and through which the consumer requests themoney transfer. Pursuant to the agreement between the funds network andthe money transfer service provider, a settlement process debits anaccount associated with the funds provider and credits the debitedamount to an account owned by the money transfer service providerthrough an automated clearing house or other electronic transaction on apredetermined settlement date. Also pursuant to such agreement, the APIpreferably reports to the funds network the transferred amount.

Similarly through the user interface, consumer 12 may allocate fundsfrom e-wallet 42 to an automatic bill paying account, such as providedby services such as PAYPAL at 24, a money order at 26, a prepaidtelephone card at 28, or other desired monetary repository.

In the presently-described embodiment, the funds network charges fees onfunds loaded to monetary repositories that are set by an agreementbetween the funds network and the repository manager. The repositorymanager therefore knows the fees that are ultimately borne by theconsumer based on the funds network, and may therefore consider thatinformation in setting its own fees. Of course, in a situation in whichthe funds network is also the repository manager, the funds network cancontrol fees related both to the funds network function and therepository function.

In one preferred embodiment, funds network 38 requires that all proceedsof a cashed check be submitted to the funds network, without retentionof a partial amount for distribution to the consumer in currency.However, after allocating the entire check proceeds to a prepaid card at20 and/or an e-wallet at 42, server 200 may prompt the consumer(directly through a user interface if the consumer is communicatingdirectly with the funds network through a funds network kiosk 208, orindirectly via an operator if the consumer is communicating with thefunds network through a manually operated check-cashing entity) torequest whether the consumer desires to receive currency in a cash-backtransaction. If the consumer replies in the affirmative and identifies asource for the funds (e.g. a prepaid card or e-wallet account), server200 instructs kiosk 208 to dispense that amount of cash to the consumerin currency, or instructs the service provider operator to do so. In theformer situation, the load network charges the dispensed amount againstan internal account and, if the consumer designated the funds be chargedagainst a prepaid account, later settles the amount with the prepaidaccount manager by electronic funds transfer. If the consumer designatedwithdrawal from an e-wallet account, the load network settles the amountwith the e-wallet account internally or, if the e-wallet account ismanaged by a third party, with the third party manager. In the lattercase, the service provider later settles the dispensed amount from fundsnetwork 38, and funds network 38 then settles with the source of thecash-back funds. Alternatively, and particularly where the serviceprovider is a retailer, the consumer may not have a cash back option. Ina still further embodiment, load network 38 loads funds directly intoprepaid or other repositories 22, 24, 26, 28 and/or 54, without anintervening e-wallet 42.

FIGS. 3A-3G illustrate one embodiment of a transaction employing asystem as described above. In operation of funds network 38 (FIGS. 2 and4), and referring to FIG. 2 and FIG. 3A, a consumer 12 presents one ormore checks 14 to the funds network, for example at a retailestablishment, or stand-alone service provider 206, or kiosk 208 (FIG.4), at 55. The kiosk, retailer or service provider obtains consumeridentification information at the kiosk 208 or retailer/service providercomputer 206, for example by prompting the consumer or operator to swipea prepaid card associated with an enrolled card issuer or enter the cardnumber by other means.

The retailer, service provider or kiosk may charge service fees forcashing the consumer's checks. This is controlled by the serviceprovider systems independently of funds network 38. For example, theretailer or service provider may have a policy to always charge acertain fee for cashing a check. If so, when the customer information isentered into the service provider's computer system at 55 as part of acheck cashing transaction, the service provider's computer system mayautomatically associate such fee amount with the customer identificationdata. Other arrangements are possible, however, and the check cashingentity may selectively waive the fee in its sole discretion. Thus, forexample, as shown in FIG. 3A, if the consumer enters customerinformation into the check cashing entity's system at 55 in the form ofa prepaid debit card number, the check cashing entity's system acquiresthe BIN from the card number and checks at 57 whether the card issuerassociated with the BIN is one with which the check-cashing entity has aretail or other commercial relationship such that the check-cashingentity waives the transaction fee. If so, then at 59, the check cashingentity passes the consumer identification information to funds network38 without the check-cashing entity surcharge.

However, if at 57 the customer identification information is not a cardnumber associated with a card issuer with which the check cashing entityhas such a relationship, then at 61 the check cashing entity may presenta question to the consumer, requesting the consumer to confirm whetherthe consumer agrees to the charge of a fee for the check cashingservice. If the consumer does not agree, the transaction ends at 63. Ifthe consumer wishes to accept the additional fee at 61, then at 59 thecheck cashing entity includes the fee amount with the data passed up tofunds network 38.

Note that in the example, the consumer identification information isacquired at 55 by the check cashing entity system, not the funds networksystem. Pursuant to a prior arrangement between the funds network systemand the check cashing entity, the check cashing entity may configure itssystem to request and acquire certain predetermined customer identityinformation that the check cashing entity then forwards to funds network38. The check cashing entity merely acquires this information; it doesnot analyze or utilize the information to actually identify theconsumer. For example, where customer identification informationcomprises biometric data, the check cashing entity system may acquirethe biometric data to pass to funds network 38, but it does not analyzethe data to identify the consumer. Similarly, where the identificationinformation is a user name and personal identification number (PIN)sequence, the check cashing entity may present such questions to theconsumer, receive the consumer's responses, and forward the responses tothe funds network 38, but the check cashing entity does not identify theconsumer based on those responses. Where the customer identificationinformation is a prepaid debit card number, whether acquired from amagnetic card swipe or keyed entry, the check cashing entity passes thecard number to the funds network without associating the card numberwith a consumer identity.

As described in more detail below, the check cashing entity may alsoacquire at 55 an image of the check, for example via a scanner locatedat computing device 206. The check-cashing entity prompts the consumerto endorse the check to the funds network, either by a specialendorsement (i.e. endorsement to the person, corporation, partnership,or other entity that controls operation of the funds network) or by ablank or general endorsement coupled with subsequent transfer of theinstrument or corresponding funds to the funds network. From step 59,computer 206 or 208 communicates the identification, endorsed checkimage (if present) and fee (if present) information to server 200 overInternet connection 210. In another embodiment, the imaged check may bepassed to the funds network without endorsement, and the funds networkprompts the check-cashing entity to acquire the endorsed check aftercheck verification. In such arrangement, the check-cashing entity wouldconfirm receipt of endorsement and so notify the funds network beforethe funds network submits a load instruction to the card accountmanager. The timing of the endorsement can vary, but in a preferredembodiment, the agreement between the funds network and thecheck-cashing entity requires the check-cashing entity to confirm theconsumer has endorsed the check and take possession of the endorsedcheck before some predetermined event or action occurs. For instance,the agreement may obligate the check-cashing entity to take possessionof the endorsed check before imaging the check and forwarding the imageto the funds network, so that the funds network interprets receipt ofthe imaged check as confirmation that the check has been endorsed to thefunds network.

Referring to FIG. 3B, funds network 38 receives a check load request at56. The check load request may comprise any format sufficient to notifythe funds network that a request has been received. In onepresently-described embodiment, the load request is simply the receiptof a reloadable debit card number from the check-cashing entity at 59(FIG. 3A). Upon receiving the card number, server 200 checks a table indatabase 202 that associates card numbers with e-wallet accounts, at 58.If the card number is not associated with an e-wallet account at 58,server 200 acquires the BIN from the received card number and checks asecond table in database 202 (or, possibly the same table, depending onthe data arrangement) that associates BIN's with card issuers andidentifies whether the card issuer is presently enrolled with the fundsnetwork. If the card issuer is not enrolled with the funds network,server 200 reports this information back to the check-cashing entityover Internet connection 210 and prompts the check-cashing entity to sonotify the consumer and recommend to the consumer enrollment with thefunds network, at 64, and the transaction ends.

If, however, the card's BIN indicates that the card is enrolled with thefunds network, then at 74, server 200 queries the card account managerfor the card issuer associated with that BIN number via an applicationprogramming interface (API) established pursuant to the enrollmentagreement between the card issuer and the funds network. As should beunderstood, the API may reside locally with the funds network orremotely at the card issuer system or a third-party data center. Thearrangement of the API, or generally the mechanism of communicationbetween the funds network and the card issuer, are notin-and-of-themselves part of the present invention and thus notdiscussed in further detail herein.

In the embodiment described with respect to FIG. 3B, the query at 74asks only for the identity of the consumer associated with the cardnumber received from the check-cashing entity, for example causing thecard account manager to return the consumer's Social Security Number orother predetermined identification indicia via the API. In anotherembodiment, however, the card account manager returns additionalcardholder data, for example the consumer's name, address, city, state,zip code, Social Security Number, tax identification number, or othersimilar information. Furthermore, the card issuer may also return datarelating to the card, for example card status (e.g. open or closed,active or inactive), card issue date, present balance, load limit (i.e.the maximum load allowable), and whether the card is associated with adirect deposit account.

At 76, server 200 checks a table in database 202 that associates thepredetermined customer identification information (for example, SocialSecurity Number) with enrollment of individuals associated with thattype of identification in the funds network. The table preferablyincludes customer information, such as name, city, state, zip code,Social Security Number, tax identification number, and similarinformation. Thus, if the customer identification is present in thetable at 76, there is no need for further cardholder data from the cardissuer. If the funds network did not acquire current card data at 74,server 200 makes a second query to the card account manager at 78through the API associated with the card issuer and requests the carddata associated with the card number passed from the check-cashingentity at 59 (FIG. 3A). Server 200 adds a record for this card number toa card data table maintained at database 202 that includes the card dataas described herein. If the server acquired the card data at 74,however, the query portion of step 78 may be omitted, and server 200saves the card data record directly from that previously obtained data.

If, at 76, the customer is not present in the customer table of database202, and if server 200 did not query the card issuer at 74 forcardholder data and card data, then at 80, server 200 queries the cardissuer through the API for both types of data. Upon receipt of thisinformation, server 200 creates a corresponding card data record, and acorresponding cardholder data record, in the card data table andcustomer table on database 202, at 82. If the server acquired thecardholder and card data from the query at 74, step 80 may be omittedand this data directly stored at step 82.

At 83, server 200 sends a request through Internet connection 210 to thecheck-cashing entity that provided the card number at 59, requestingthat the check-cashing entity provide an image of the underlying checkor checks involved in the load transaction, endorsed by the consumer.This prompts the check-cashing entity to request the consumer to endorsethe check to the funds network and to acquire a check image, for exampleby scanning the endorsed check at computer 206. Server 200 awaits thereturned image of the endorsed check. In another embodiment, thecheck-cashing entity may acquire the endorsed check image initially, sothat the check-cashing entity passes the check image along with the cardnumber as part of the check load request from 59. In that event, step 83may be omitted. As noted above, the consumer may endorse the check tothe funds network by a special endorsement (e.g. “pay to the order of[the funds network]”) or by simply endorsing the check with theconsumer's signature. The funds network may acquire possession of thecheck via the Check 21 procedure as discussed below, and/or may acquirepossession of the funds corresponding to the check.

Whether obtaining the check image from step 59 or step 83, at 84 server200 examines the image and acquires the maker identification from themagnetic ink character recognition (MICR) data in the image. At 88,server 200 checks a transaction record table of database 202. Eachrecord of this table, for example, includes maker identification, checktype, check amount, transaction date, payee (consumer) identification,load recipient (i.e. card issuer), and transaction result (for examplecheck cashed or not, check cleared or not, and/or load successful orunsuccessful) for a past load transaction. In the presently-describedembodiments, database 202 includes transaction records for all pasttransactions conducted through the system in which a negotiableinstrument was requested to be converted to funds, for instance for allmakers and all payees. Server 200 retrieves at 88 all such recordslisting the maker identified at 84. At 90, server 200 retrieves fromthis table all such records listing as payee the consumer identified at74. Thus, the server retrieves all transaction records stored indatabase 202 for the maker involved in the present transaction,regardless of consumer, and all transaction records available in thedatabase involving the consumer, regardless of maker or card issuer.

Server 200 compiles the transaction data retrieved at 88 and 90 into arequest for guarantee at 91 and transmits the compiled data in anauction request to one or more check guarantor entities 94, at 92.

Referring also to FIG. 3C, as indicated at 96, the sequence by which theauction offer can be transmitted/offered to the plurality of checkguarantors 94 can vary. In a sequence indicated at 98, for example, theload network transmits the offer sequentially, asking first one, andthen a next, guarantor entity 94 until a guarantor accepts the offer.The order in which guarantors are queried may be established in variousways, e.g. by a randomly generated sequence or by a predetermined orderin which slots in the order are reserved by the guarantors in theenrollment process with the funds network.

Referring to the detail of procedure 98 at FIG. 3D, server 200 checks atable in database 202 at 85 to determine the first guarantor 94 to whichto submit the request for guarantee. Server 200 submits the requestelectronically over a network connection to the first check cashingguarantor 94 indicated at 85, pursuant to a pre-existing agreementbetween the guarantor and the funds network enrolling the guarantor withthe funds network. If the first vendor identified at 85 accepts therequest, and agrees to guarantee the check, at 87, the check guaranteeprocess is concluded at 104. If the first check cashing guarantor 94does not accept the request, or does not approve the check, at 87,server 200 submits the request to the next check cashing guarantorindicated at 85, at 89, again pursuant to an enrollment contract. Ifthis guarantor accepts the request and agrees to guarantee the check,the check cashing guarantee procedure ends at 104. If not, server 200submits the request sequentially to the check cashing guarantors in theorder identified at step 85, repeating the process until either a checkcashing guarantor guarantees the check, thereby advancing the process tostep 104, or all check cashing guarantors either refuse the processand/or reject the check at 93. In the latter event, the customer isnotified via the check-cashing entity at computers 206 or 208 at 95 thatthe check has been declined. Server 200 stores a data record reflectingthe transaction (e.g. check maker, check type, check amount, and result)in the transaction record table of database 202, and the processterminates.

Returning to FIG. 3C, in a sequence indicated at 100, the funds networksimultaneously submits the auction request to all guarantors 94 enrolledwith the funds network, selecting the first guarantor 94 to accept theoffer. In a sequence indicated at 102, the load network selects aguarantor 94 in an order based upon a predetermined criterion orcriteria, selecting the first guarantor 94 to accept the offer. Thecriterion or criteria can vary as desired and is not, in and of itself,a part of the present invention. For example, the server may selectguarantors based on fees, going first to guarantors with lower fees,and/or transaction-based criteria, such as whether guarantors havepreferences for transaction amount ranges or check types.

As should be understood in the check-cashing art, the check guarantoranalyzes the check data and the customer data and makes a decisionwhether to guarantee the check. If, at 104, the selected check guarantor94 transmits to the load network 38 an approval to cash the check, thefunds network deducts the check cashing entity's fee (if any) receivedfrom 59 (FIG. 3A) and an interchange fee (described below) from thecheck proceeds at 106, credits a funds network-owned account by the feeand interchange amounts, and records the fee and interchange amounts ina table at 107. The funds network immediately transmits instructions tothe card issuer identified from the card data received from 59 to loadthe customer's account associated with the card with the remaining checkproceeds, at 108. Funds network 38 provides these instructions via anAPI pursuant to an enrollment agreement between the funds network andthe card issuer. In this instruction, the funds network identifies theconsumer, the card number, and the load amount. From its local accounts,the card issuer deposits funds equal to the load amount into an accountassociated with the card number. From the card issuer's perspective, thefunds network is liable to the card issuer for the funds, regardless ofthe underlying check's validity. Typically, although not necessarily,the funds network and the guarantor 94 that guarantees the check have anagreement under which the guarantor assumes the risk of loss if thecheck is returned. The funds network transmits a receipt to the customervia the check-cashing entity and computer 206 or 208, at 112.

Alternatively, the funds network may transfer funds to the card accountmanager at step 108, rather than sending instructions. In that event,the funds network would not transfer funds to the card account managerat step 127 (described below), and that step can be replaced by a stepof applying check proceeds to a funds network account, if the checkclears. Moreover, in the procedure described with respect to FIGS. 3Fand 3G, the funds network initially deposits the check into a fundsnetwork account, submits the check for settlement, and forwards fees tothe card manager, whereas in the procedure described below with regardto the FIGS. 13 and 14, the funds network initially deposits the checkin an account owned and controlled by the issuing bank, which submitsthe check for settlement and transfers fees to the card manager andultimately the funds network. It should be understood that eitherapproach may be utilized with either of the check conversion proceduresdescribed with respect to FIG. 3 or 8-12.

At 110, and also referring to FIG. 3E, the funds network deposits theface amount of the underlying check (i.e. the amount for which the checkwas made, without reduction for any fees) in a funds network fiduciaryaccount at a clearing bank, and electronically transmits a copy of theimage of the check for settlement via the Check 21 protocol to theclearing bank. At 111, the funds network adds a data record to thetransaction record table at database 202, recording the consumeridentity, maker identity, check number, check type, check amount,check-cashing entity identification, date, interchange and check-cashingentity fees, and the identity of the card issuer receiving load. Asshould be understood, under the Check 21 protocol, a substitute check,or image replacement document, is created by or for the funds network.As should also be understood, the Check 21 settlement procedure requiresthat a check be cleared within a two day period. If the check clears at113, then at 115, the funds network updates the transaction record forthis check in the transaction record table at database 202, and thispart of the process ends. The check maker's bank forwards the check faceamount to the clearing back noted above. In turn, the clearing bankforwards the check face amount to an account designated by the fundsnetwork. The funds network distributes the check proceeds as describedin more detail below.

If the check does not clear at 113, the clearing bank receives notice ofthe returned check at 117. The clearing bank notifies the funds networkof the returned check, and the funds network appends the returned checknotice to a table in database 202 that holds information relating toreturned checks, at 119, and updates the check's transaction record indatabase 202 to indicate a returned check, at 115. At 121, pursuant toan agreement between the funds network and the check guarantor thatguarantees the check, the funds network provides notice to the checkguarantor, for example automatically through an API established pursuantto the enrollment agreement, that the check was returned and requestingthat the guarantor indemnify the funds network for the check faceamount. In response, the check guarantor transfers, for example byelectronic funds transfer or automated clearing house transfer, the faceamount of the check to an account designated by the funds network.

In another embodiment, the funds network does not present the checktransaction to a guarantor selection procedure, but instead accepts theliability within the funds network alone. In that instance, andreturning to FIG. 3B, the funds network acquires the information fromstep 84 and makes its own assessment whether to approve the check. Inthis instance, the funds network computer system receives confirmationto fund the check from the funds network entity as part of the entity'sinternal operation. Thus, and referring to FIG. 3C, the funds network'sdecision is reflected at step 104, and the process proceeds from thatpoint as discussed above, except that in the event the check is returnedat step 113 (FIG. 3E), step 121 is omitted, and loss on the checkremains with the funds network.

Regardless whether the check clears, and referring to FIG. 3F, after thecheck is submitted for settlement at steps 110-111, the funds networkpauses for a predetermined period of time, for example two businessdays, to permit the check to clear and funds to be returned from thecheck, as indicated at 123. After the pause, and again regardlesswhether the underlying check clears, the funds network allocates thetotal face amount according to the steps indicated at 125, 127, and 129.At 125, the funds network allocates the interchange fee to the fundsnetwork. This is an accounting remittance and does not necessarilyinvolve an actual transfer of funds, although it is possible to movefunds between funds network accounts for this purpose.

The interchange is a fee established by agreement between the fundsnetwork and the card issuer to which the load amount is sent at 108(FIG. 3C). The interchange can be established in any manner agreeablebetween the parties, but in this example is set as a percentage of thecheck face amount, for example 3%. Thus, at step 127, 3% of the checkface value is allocated to the interchange. The interchange may also bereferred to herein as the funds network fee.

At step 129, the initial fee charged by the check-cashing entity andreported to the funds network from 59 (FIG. 3A), if any, is transferredby the funds network, for example by electronic funds transfer orautomated clearing house transfer, from a funds network account to thecheck cashing entity. At 127, the remainder (i.e. the check face value,less the interchange and the check-cashing entity fee) is transferred bythe funds network from a funds network account to the card issuer.

At 131, 133 and 135, the funds network allocates a portion of theinterchange to costs associated with the transaction. For instance, ifthe funds network obtains a guarantee of the check from a checkguarantor 94, there will generally be a per-transaction fee owed by thefunds network to the check guarantor pursuant to an agreement betweenthose parties. The funds network therefore transfers this fee at 131from a funds network account to the check guarantor. Similarly, thefunds network and the check-cashing entity may have an agreement underwhich the funds network remits to the check-cashing entity aper-transaction fee. This fee is independent of fees that thecheck-cashing entity may charge the consumer as shown in FIG. 3A. At133, the funds network transfers this fee amount from a funds networkaccount to the check-cashing entity. Moreover, as should be understoodin the art of settlement transactions, there are costs associated withthe settlement process, and the funds network may transfer funds from afunds network account at 133 to pay these costs. The difference betweenthe interchange fee and the sum of the fees and costs paid at step 131,133 and 135 represents the per-transaction net revenue to the fundsnetwork.

Referring now to FIG. 3G, if the check load request from step 56indicates at 58 (FIG. 3B) that the customer has an e-wallet account withthe funds network, then steps 62 through 74 in FIG. 3B are unnecessary,and the answer to step 76 is “yes.” Accordingly, server 200 executessteps 78-135 as discussed above with respect to FIGS. 3B-3D, 3E, and 3F,except that step 108 changes to transfer of funds to the funds network'se-wallet associated account and an update of the consumer's record inthe funds network database to reflect the increased e-wallet balance,and that settlement at step 127 is to the funds network e-walletaccount. If a check-cashing guarantee is not obtained at 104, thetransactions ends, and the data store is updated, at 95, as discussedabove. If, however, a check guarantee is obtained at 104, the loadnetwork submits the check for processing and settlement at 110 (FIG.3C). At step 127 (FIG. 3F), server 200 (FIG. 4) allocates to thecustomer's e-wallet account identified at 58 the check proceeds, lessthe interchange and check-cashing entity independent fee.

If the consumer wishes, at this or a later time, to withdraw funds inthe e-wallet account (whether maintained by the funds network or a thirdparty), the consumer may access the account through the funds network orthird party independently of the load and allocation functions discussedherein. If, however, the consumer wishes to allocate funds from thee-wallet to a monetary repository maintained by a manager enrolled withthe funds network to receive good funds, the consumer may access fundsnetwork server 200 directly via a funds-network owned kiosk 208 or aconsumer-controlled computer 206 (FIG. 4), such as a mobile telephonewith a suitable application, at 114. Alternatively, if the consumerexecuted a load transaction discussed above via a direct connection withthe load network over such a device, the consumer may execute an optionthrough the funds network user interface to move from loading mode toallocation mode, as indicated by the line between 110 and 111 in FIG.3G. Upon accessing the funds network through such a connection andindicating a desire to disburse funds from the e-wallet at 114, server200 presents to the consumer (via a user interface presented at theconsumer's computing device) a query whether the consumer wishes todisburse funds from its e-wallet account to an existing monetaryrepository associated in a table of database 202 with that e-walletaccount, at 116. If the consumer indicates at 116 that the consumer doesnot wish to load e-wallet funds to an existing repository, server 200prompts the consumer or operator to enter information identifying thenew repository. In response to the prompt, for example, the consumer oroperator swipes or otherwise identifies or images a new card at thecomputer 206 or 208, or other computing device, at 120. If the BINportion of the new card number does not match an enrolled card issuer,the transaction ends, as at 95. If the BIN does match a card issuer,then at 120 server 200 queries the card issuer via the API associatedwith that issuer, obtains card data, and creates a record in thedatabase table, associating the new card with the e-wallet account, at122.

If the customer indicates that it wishes to disburse funds from thee-wallet account to an existing repository at 116, server 200 queriesdatabase 202 to identify from the database table thosecustomer-associated repositories that are available to this particularcustomer. For example, the particular consumer may have set up anaccount to enable the consumer to pay utility or other personal bills,and/or an account by which the consumer may make money transfers 22,and/or two reloadable debit cards 20. If the consumer has a directdeposit bank account, the customer may also disburse funds from itse-wallet account to the direct deposit bank account, as indicated at126.

Having identified the available consumer-associated accounts at 124,server 200 presents via the user interface a selection window throughwhich the customer selects the desired customer-associated account orother repository, at 128. Server 200 then queries the consumer via theuser interface to enter the amount of the desired disbursement. Theconsumer enters this information to server 200 via computer 206 or 208or other computing device at 132. If the requested load amount is withinthe amount present in the e-wallet account, the requested load amount isaccepted, and a fee charged by the funds network pursuant to thee-wallet or, alternatively, is allocated in addition to the load amountagreement between the funds network and the consumer is deducted fromthe requested load amount. At 134, the funds network debits its (orrequests a debit of the third party) e-wallet account by the load amountand the fee, and the funds network sends a load request to the requestedcustomer-associated account or repository, as at step 108 (FIG. 3C).Pursuant to the contract between the load network and the repositorymanager, the load amount is settled between an account owned by the loadnetwork and an account owned by the account manager in due course. Thefee is settled from the e-wallet account to a funds network account. At136, server 200 notifies the customer via the user interface of theremaining balance in the e-wallet account.

At 138, server 200 queries the customer via the user interface whetheran additional load is desired. If the customer responds in the negative,server 200 transmits to the customer via the user interface a receiptfor the transaction, at 112. If the customer desires another loadtransaction at 138, the procedure returns to step 118.

FIGS. 5-14 illustrate further embodiments of a system for acquiring andconverting negotiable instruments to funds. The embodiments areparticularly described in the context of negotiable instrument capturevia a device 208 remote from a human operator, but it should beunderstood that other aspects of the embodiments, for example the loadand settlement process, and the use of selectable deposit types and/orselectable fees, may be used in the context of negotiable instrumentsacquired at manned facilities as well.

In the embodiments described above with respect to FIG. 3, the payeeprimarily presents a negotiable instrument to the acquirer in person,manually transferring the physical instrument to the acquirer. As notedabove, however, the system may acquire the instrument via a device (suchas a mobile telephone, kiosk, or automated teller machine) that isremote from the acquirer's human operators. The methods illustrated byFIGS. 5-14 particularly facilitate a negotiable instrument's acquisitionvia a device that is geographically remote from the acquirer humanoperators (in that the human operators do not interact with the payee inperson), and the instrument's sub sequent processing.

In this regard, where the funds network and/or a reloadable card managercharge transaction fees that depend upon the negotiable instrument'sclassification to one of a plurality of types of maker, that maytherefore require human examination of the instrument to determine thetype, the methods described below include an initial transmission of animage of the instrument to the funds network. The funds networkclassifies the instrument according to maker type (e.g. insurancechecks, personal checks, government checks, pay roll checks, etc.),determines an applicable fee based on the classification, and returns afee query to the remote payee. Fees may vary by maker, for example,because the frequency of fraud can vary with maker, as can the level ofsteps taken to prevent fraud. Through the user interface on the remotedevice, the payee may accept the fee, thereby continuing thetransaction, or refuse the fee, thereby ending the transaction. Wherethe user interface on the remote device is an application controlled bya reloadable card manager, the card manager can directly control aportion of the fee amount attributable to the card manager on a realtime basis.

Second, a given process for converting a negotiable instrument to fundsmay, depending on circumstances, call for holding the instrument for aperiod of time in which it is expected that the instrument wouldcomplete the settlement process, before converting the instrument tofunds. In such circumstances, the method described with regard to FIGS.5-14 allows the payee to submit the instrument to the funds network fromthe remote location but delay the instrument's conversion to funds untilcompletion of such period.

It should be understood that the one or more embodiments described withrespect to FIGS. 5-14 are implemented at least partially as and/or usingcomputer programs for use with a computer system such as shown at FIG. 4and described herein. That system's computers, program, and databaseseffect the various functions of these embodiments (e.g. as reflected inthe flow diagrams discussed below), and it should be understood,moreover, that the computer programs can be contained on a variety ofcomputer-readable media, as discussed above with regard to theembodiments of FIG. 3. Client computer systems (e.g. automated tellermachines, kiosks, and/or mobile telephones) 208 (FIG. 4) as describedherein include user interfaces that enable network communications withother systems, e.g. funds network server 200, over the network asdiscussed above.

FIGS. 5-14 illustrate flow diagram views of methods for convertingnegotiable instruments to funds according to various embodiments of thepresent invention. Each of these Figures illustrates “swimlanes” thatdescribe activities of respective devices or entities within orutilizing the network of FIG. 4. The column headings, however, aregenerally functional rather than entity-specific, and the presentdiscussion therefore generally identifies the device or entity thatperforms a function identified by a given swimlane step. It should beunderstood, however, that the specific allocations of functionsdisclosed below is provided for purposes of example only and that otherdevices or entities in other columns or swimlanes could perform givensteps in certain circumstances or embodiments. As illustrated, theswimlane column headings are “Customer,” “Interface with Customer,”“Funds Network,” “Third Party Check 21 Processor,” “Issuing Bank,” and“Card Processor/Program Manager,” each of which is discussed below.

As discussed in these Figures, the funds network performs variousfunctions and/or steps involved in processing a check presented by apayee (the term “payee” should be understood to encompass an originalpayee or a later transferee/holder in due course). The funds network isembodied by one or more computer servers and databases, such as thecomputer servers 200 and databases 202 of FIG. 4. The funds network maybe comprised of multiple servers and databases, whether located locallyand networked through a local area network or distributed through a widearea network or an Internet connection. In general, the funds networkperforms the functions identified in the “Funds Network” swimlanes, butit should be understood that some functions are performed by the cardmanager server or the Check 21 processor, as may be indicated in thediscussion below.

The “customer” is the negotiable instrument payee. The “customer”swimlane generally illustrates functions performed by the payee, forexample using a graphical user interface embodied by computer softwarethat is located and operates on a mobile telephone, ATM, kiosk or othermobile or remote device 208 (FIG. 4) to visually present the interfaceto the payee, although other entities, for instance the card manager,may perform some functions as may be indicated in the discussion below.The customer interface allows the payee to enter and receive informationto and from one or more entities involved in the transaction. Forexample, the customer interface may be a graphical user interface on anATM, mobile telephone, or kiosk that allows the payee to input customerinformation and interactively respond to requests made by such otherentities. The “Interface with Customer” swimlane generally includesfunctions performed by the device interface or the card manager, but mayencompass functions performed by other entities.

In general, it is not necessary that the entity that owns and/orcontrols the operation of the device 208 also provide the user interfaceon that device. A reloadable debit card manager entity, e.g. GreenDot®or H & R Block®, may own and place an ATM or kiosk, and also create andload the user interface, but it is also possible that the card managercreates a user interface that is used on or accessed by an ATM or kioskowned and operated by another party. Further, in certain embodiments inwhich the acquiring device operates on a mobile telephone, a cardmanager or funds network may provide a downloadable mobile telephoneapplication on a telephone owned and operated by the payee.

The “Third Party Check 21 processor” refers to an entity that performsautomated clearinghouse operations to settle check-type negotiableinstruments. In the embodiments described herein, the “third party Check21 processor” is an entity distinct from the funds network, but itshould be understood that the funds network can perform the functionsassociated with the Check 21 processor herein.

The “issuing bank” is a bank that sponsors a reloadable debit cardmanager's card program. As discussed above, the issuing bank owns theaccounts into which funds are deposited in association with a debit cardaccount managed by the card manager, to thereby load the card. Theissuing bank provides permission to the Check 21 processor to settlefunds into the issuing bank's accounts from the funds network to beloaded onto the card account managed by the card manager for the payee.Having received a check from the payee via the customer interface, thefunds network presents the check to the issuing bank for payment via theCheck 21 processor. It should be understood, however, that thisarrangement is described for purposes of explanation and that othersettlement processes could be utilized, for instance includingforwarding funds to the bank via ACH or wire transfer.

The “Card Processor/Program Manager” is the card manager entity—i.e. theentity that manages transactions between the issuing bank and entitiesdesiring to make debits against reloadable debit cards. The card manageralso manages funds loads onto cards, in conjunction with the fundsnetwork as described herein.

In presently described embodiments in which the payee submits funds to areloadable debit card, the payee enrolls both with the reloadable debitcard manager and the funds network. As described herein, multiple cardmanagers may enroll with the funds network so that the funds network isable to manage card load transactions with multiple different cardmanagers. That is, the funds network is not simply a card debit/loadnetwork captured by a single card manager, but rather a card loadnetwork that is accessible by multiple card managers. Thus, enrollmentwith both the card manager and the funds network, and identification toboth the card manager and the funds network in a given transaction,defines the transaction's path between the payee and the payee'sreloadable card. In general, the card manager may require enrollment inorder to associate the payee's identification with security measures tothereby confirm the payee's identity when the payee accesses the cardmanager's system. The card manager may require such security measureseven when the payee interacts directly with a human operator but, in thepresently described embodiments, requires such measures when the payeeaccesses the card manager's system via a device (such as a mobiletelephone, kiosk, or ATM) that is geographically remote from the humanoperator. Such security measures may also facilitate the payee's use ofcard manager services other than negotiable instrument conversion, inthose instances where the card manager provides other types of services.The payee's enrollment with the funds network allows the funds networkto locate information needed to confirm that the payee's instrumentshould be converted to funds and, if so, to properly direct theinstrument proceeds to a desired monetary repository.

As described below with respect to FIGS. 7A-7B, the payee may havepreviously enrolled with the debit card manager to set up a card accountby which the payee can load the card through various means and use thecard to make debit purchases. As part of this process, indicated at 502in FIG. 5, the card manager may collect certain information about thepayee, e.g. the payee's name, address, telephone number, date of birth,card account number, and social security number, and the load networkassigns a unique member ID token to the payee for the payee's use inassociation with the payee's reloadable debit card when loading checks.In determining whether to accept the payee as a customer, the cardmanager may conduct a credit search against the payee and thereby obtaina credit score applicable to the payee. If the card manager accepts thepayee as a customer, the card manager may assign the payee to a cardnumber or other identifier that associates with the payee a card thatthe card manager assigns to the payee. All of this information,including the payee-specific personal information, the thirdparty-generated credit score, and the acquirer-assigned card number, isreferred to herein as “customer information,” and while it should beunderstood that the customer information may include the informationexplicitly described herein, it should also be understood that theparticular elements of customer information may vary as needed and/ordesirable within a given system.

The customer information is helpful to the funds network because itidentifies a payee who may wish to use the funds network to convert anegotiable instrument to funds and allows the funds network to associatethat customer identification with the monetary repository (in thisinstance, the card, as identified by the assigned card number) to whichthe instrument proceeds may be directed. Moreover, the remainingcustomer information can be helpful in assessing whether the fundsnetwork will accept a negotiable instrument that the payee later submitsfor conversion to funds. Accordingly, during the card enrollmentprocess, the card manager queries the payee whether the payee wishes tobe able to reload the card with proceeds of negotiable instruments thepayee may later submit through the funds network. If the payee respondsaffirmatively, the card manager, at 502, sends the customer informationto the funds network (via any suitable method, e.g. hard copy mail,voice telephone communication, wireless message, or network/Internetcomputer communication), which in turn enrolls the customer with thefunds network, at 504. In so doing, the funds network generates a memberidentification (member ID) unique to the payee within the funds networkand associates that member ID with the payee's name, reloadable cardnumber, and other customer information in database 202 (FIG. 4). Itshould be understood, however, that this method of enrolling the payeein the funds network is presented solely for purposes of explanation andthat other methods could be used.

For instance, where the payee chooses not to enroll with the fundsnetwork at the time the customer enrolls with the card manager, thepayee may later enroll with the funds network by interacting directlywith the funds network, e.g. through an Internet connection or a mobiletelephone application provided by the funds network, and providing thepersonal customer-specific information through an interactivequestion-and-answer function on the mobile application or on a web pagemaintained by the funds network entity. The funds network may allow thepayee to directly enroll with the funds network, and thereby obtain amember ID, without having a reloadable debit card. Such payees may, forexample, convert check proceeds to funds by directing check proceeds toan e-wallet or to distribution as currency. Alternatively, and referringto FIG. 6, the payee may enroll with the funds network at the time thepayee attempts to convert a negotiable instrument to funds and depositthe instrument proceeds to a reloadable card. At 602, for example, thepayee may insert the reloadable card into an automated teller machineoperated by a bank or other entity having a relationship with the fundsnetwork (such that the ATM programming provides an option (selectable bythe payee via the ATM interface) to connect with the funds network), orinsert the card into a kiosk controlled by a similar entity. The ATM orkiosk reads the card number from the card's magnetic stripe and promptsthe payee to enter the payee's PIN. The ATM or kiosk operator (ifdifferent from the card manager) has a relationship with the cardmanager identified by the card number such that the ATM or kioskprogramming communicates the card number and payee-supplied PIN to thecard manager. The card manager server compares the PIN to the PIN storedin the card manager's database for this card number. If there is amatch, the card manager server sends confirmation to the ATM or kiosk.The ATM or kiosk forwards the card number to the funds network via asecure Internet or other network connection. The funds network server200 (FIG. 4) then checks whether this card number is associated with acurrently-enrolled customer record, as at 58 and 62 in FIG. 3B. If themember ID is associated with an e-wallet, then the answer to the queryat 606 (described below) is “yes,” and the steps following 606 occur asdescribed below, except that steps 924 (FIG. 9B) and 1040 (FIG. 10B)refer to a transfer of funds to an e-wallet account and an update of thefunds network database to reflect the increased e-wallet balance.Similarly, after step 1214 in FIG. 12B there is a check to confirmwhether the transaction is for an e-wallet, a flag set that is detectedafter step 1250, followed by a similar e-wallet account transfer offunds and database update.

If the card number matches a record, the funds network server sets anaccept flag at 614 and notifies the payee via a message to the ATM/kioskto continue with the transaction, as at 622. The ATM or kiosk thenrequests the payee to submit the image of the check, as shown at 806 inFIG. 8A and 83 in FIG. 3B, endorsed by the payee. As noted above, theendorsement can be made specially to the funds network, or can be ablank or general endorsement. Where the funds network acquirespossession of the check via the Check 21 protocol at 812 (FIG. 8B), thefunds network becomes the check holder. The remainder of this procedureis described below with respect to FIGS. 8A-8B.

If the payee accesses the system through a mobile telephone application,the mobile telephone application prompts the payee for the payee'smobile user ID and password. Upon receiving this information, the mobileapplication causes the mobile telephone to transmit this information tothe card manager server, which in turn confirms the payee's identityand, if the payee has a funds network member ID, passes the member ID tothe mobile telephone application. The mobile application causes thetelephone to forward the member ID to the funds network, and theprocedure continues in the same manner as discussed above for ATM orkiosk transactions.

As should be understood, these communications can be encrypted byvarious techniques that should be well known and that are therefore notdiscussed in detail herein. While it should be understood that varioussecurity measures can be employed, the present discussion refers simplyto the conveyance of data and information.

Although not illustrated in FIG. 6, if the PIN does not match the cardmanager's PIN for the card number in a kiosk/ATM transaction, or if theuser ID and password do not match the card manager's stored user ID andpassword for this card number in a mobile telephone transaction, thecard manager sends a message back to the ATM, kiosk or mobile telephone,instructing the remote device to display a message to the payee that thepayee's identification information is incorrect, and requesting that thepayee re-enter such information or end the transaction. While the payeemay re-enter the information to re-try the transaction, thereby startinga new transaction, the present transaction can be considered to end.

If the card manager verifies the card number and PIN, the ATM/kioskforwards the card number to the funds network to confirm whether thecard is enrolled with the funds network, at 604. At 606, the fundsnetwork server establishes a transaction record in database 202 (FIG. 4)for the payee's request and then queries database 202 with the cardnumber to determine if the card number matches a card number stored in adatabase record in association with previously-stored customerinformation. If there is no such match, the funds network determinesthat the payee is not enrolled with the funds network and may (althoughthis path is not shown in FIG. 6) directly set a status flag in thetransaction record to “decline,” as indicated at 616. If a match doesexist, the funds network sets the transaction record flag to an “Accept”value at 614.

As used herein, “flag” refers to a value in memory or database that isselectable by computer program in response to a fulfilled condition.Server 200 returns the flag value from 614/616 to the ATM/kiosk/mobiletelephone interface, at 618.

In one embodiment, if the card number does not match a customer recordin the funds network database at 606, the funds network serveridentifies that portion of the card number that identifies the cardmanager (the bank identification number, or BIN). The funds network andthe card manager have a contractual relationship that governs the mannerin which transactions involving the parties are handled, and the fundsnetwork establishes records in database 202 that associates the cardmanager's identity to BINs of reloadable cards managed by the cardmanager. Accordingly, the funds network server compares the payee card'sBIN with BINs of those card managers in the funds network database thatare funds network participants. If the card's BIN does not match anyparticipant's BIN stored in the funds network database, the fundsnetwork server sets the transaction record flag to “Decline” at 616.

If, at 608, the payee's card does match an existing card manager BIN inthe funds network database, the funds network queries the card manager(via an Internet or other network connection) for the customerinformation associated with the card number. If permitted by applicableregulations and agreements among the funds network, the card manager,and the payee, the card manager returns the payee's customer informationat 610, and the funds network enrolls the payee in the funds networkdatabase as a customer, at 612, and sets the transaction flag to“Accept” at 614. The funds network server creates a member ID and, at612, stores the member ID in the funds network database in associationwith the card number and other customer information, and provides themember ID to the card manager server.

At 618, upon receipt of the flag status, the ATM/kiosk/mobile telephoneinterface program determines whether to accept or decline the card. Ifthe received flag value is “Decline,” the interface provides anotification to the payee at 620 that the card has been declined becausethe card is not enrolled with the funds network. The notification mayfurther state how the payee can become enrolled in the funds network,such as by obtaining a new re-loadable card. If the received flag valueat 618 is “Accept,” the interface provides a notification at 622 thatthe payee is allowed to proceed to initiate conversion of a negotiableinstrument to funds through the funds network.

The procedure discussed above enrolls the payee in the funds network,thereby generating a member ID and allowing the payee to access thefunds network through a manned check-cashing entity 206 (FIG. 4) or anATM or kiosk, at which identity confirmation is accomplished through thepayee's PIN. The mobile application, however, does not operate with aPIN. Instead, as shown in FIGS. 7A-7B, the system establishes a usernameand password protocol for logging into the mobile application, andrequires the funds network to activate the application. The two generalsteps are taken with two different parties: (1) the payee creates anaccount with login credentials with the card manager (blocks 702-708);and (2) the funds network activates the payee's mobile application toperform deposit operations on the funds network (blocks 710-728). Thefirst stage allows the payee to log into the payee's telephoneapplication, and the latter stage allows the funds network to authorizethe payee's mobile deposits capture application to perform checkpre-approval processes on the funds network.

At 702, the payee interacts with a setup routine in the mobile telephonecustomer interface (i.e. a routine forming a part of the mobile depositscapture application on the payee's mobile telephone) to identify thepayee by card number and to create an account with the card manager anda user ID and password for the account. The interface provides fillableareas soliciting the payee to select a user ID and password, each ofwhich may be a series of alphanumeric characters. After the payee hasentered a proposed user ID and password, the interface causes the mobiletelephone to transmit the user ID and password to the card manager overa cellular telephone network and possibly an Internet connection.

At 704, an automated server application at the card manager's sitecompares the user ID entered by the payee with user IDs stored in adatabase controlled by the card manager that stores data identifyingindividuals who have previously enrolled with the card manager. If amatch exists, the proposed user ID is not unique, and the server sendsan instruction to the mobile application to present a notification tothe payee, at 706 to enter a different user ID, and processing returnsto block 704.

On the other hand, if the user ID is unique to the card manager at 704,the card manager server enters and stores the unique user ID, and itsassociated password in the card manager's database at 708, therebyassociating the user ID and password with the payee's account andallowing the payee to thereafter log into the mobile deposit captureapplication.

The card manager server then instructs the mobile telephone interface todisplay a request that the payee enter the payee's name and fundsnetwork member number, so that the funds network can activate thepayee's mobile deposit application to allow the negotiable instrumentdeposit. As noted above, the card manager stores funds network membernumbers in its database in association with card numbers, and so innotifying the payee that the user ID and password have been accepted,the card manager server may also retrieve and forward to the payee (viathe telephone interface) the payee's funds network member number. At710, the payee enters the payee's name and funds network member numberinto the mobile application's user interface, and the mobile applicationactivates the mobile telephone to transmit the username and membernumber to the funds network server. At 712, the funds network serverchecks its internal database and determines whether the entered membernumber exists in internal database 202 (FIG. 4). If the queried membernumber does not exist in the database, the funds network server notifiesthe payee, via communication with the mobile device interface, that thecustomer number is incorrect. The payee may then re-enter the fundsnetwork customer name and number at 710.

If the funds network database has the member number, then at 716, thefunds network server determines whether the customer name associated inthe funds network database with the same member number as submitted withthe payee's query (and located in the funds network database at 712)matches the customer name submitted in the payee's query. If this queryreturns a null value, the funds network sets an acceptance flag value to“False,” at 717 and passes the “false” value to the mobile telephoneinterface.

If the query returns a matched customer name and member number, thefunds network server activates the funds network account for remoteaccess, thereby activating the payee's mobile deposit application, at718 and sets the acceptance flag to “True” at 720. At this point, thefunds network server allows the payee to initiate negotiable instrumentdeposits via the funds network using the mobile application (as isdiscussed below). The funds network transmits the flag value from 717 or720 to the mobile telephone interface at 722.

If, at 722, the interface receives a “False” response from the fundsnetwork server, the interface notifies the customer at 724 that thesubmitted member number and customer name do not match.

If, at 722, the interface receives a “True” return from the fundsnetwork server, the interface causes the telephone to transmit thisinformation to the card manager server, and at 726, the card managerserver links the payee's user ID and password to the customer's mobiledevice and member number in the card manager's local database. The cardmanager server links the user ID and password to the customer's mobiledevice by identifying the mobile device's unique ID and storing themobile device's ID and the member number in a database entry associatedwith the payee. The card manager server then notifies the payee, via thetelephone interface, at 728 that the payee's account is now active,thereby allowing the payee to deposit negotiable instruments through thefunds network using the mobile deposit application.

In one embodiment, each of the card manager's and the funds network'sdatabases has only one entry per customer payee so that the databaseonly includes one member number, customer name, and possibly user ID,etc. for each payee. This ensures that one payee does not enrollmultiple times and facilitates quick and accurate identification ofpayee account at issue. Operations between the card member server andthe funds network server occur over a network, such as a LAN, WAN, orthe like. Each database may include one or more servers.

FIGS. 8A-8B illustrate an initial portion of a method 800 by which apayee deposits a check to a reloadable debit card using an ATM, kiosk ora mobile deposit capture application on the payee's mobile device, inwhich the system determines fees applicable to the transaction. Steps802 and 804 summarize the steps described above with respect to FIG. 6.If by a mobile device, at 802, the payee logs into the mobile depositcapture application on the payee's now-registered mobile device byproviding the payee's previously enrolled credentials (e.g., user ID andpassword, as described with regard to FIGS. 7A-7B) to the card managerserver for verification, at 804. If by ATM or kiosk, the payee swipesthe reloadable card, and enters the payee's PIN, at the device, whichthen provides the card number and PIN to the card manager forverification, at 804. If, at 802, the payee attempts to authenticatewith credentials that are not associated with a funds network member ID,then the card manager initiates enrollment with the funds network, asdiscussed above with respect to FIG. 5.

If authentication is successful, the card manager server notifies thecustomer interface, which prompts the payee to endorse the check to thefunds network and then scan or otherwise image the check. The payeeendorses the check in favor of the funds network and inputs variousdata, including the dollar amount of the check and the type of deposit(discussed below), and possibly other information as desirable in agiven system, via the mobile telephone interface, at 806. The payee theninitiates imaging of the front and back of the check by any means, suchas by a scanner incorporated or associated with the ATM or kiosk, or bythe payee's mobile device camera, or the like. If the payee isdepositing a check with the ATM, the payee inserts the check into theATM, and a scanner in the ATM images both the front and back of thecheck, and the ATM forwards the scanned front/back check image to thecard manager server under the control of the interface. If the payee isdepositing the check with the payee's mobile device, the mobile depositapplications interface instructs the payee to take images of the frontand back of the check. The camera of the payee's telephone (or otherremote device) then images of the front and back of the check. After theimages are captured, the GUI prompts the payee whether to transmit theimages to the funds network. If the payee selects an activation means(e.g., depressing a button) indicating the payee wants the mobiletelephone to transmit the images, the mobile telephone transmits theimages to the card manager server over the cellular network.

The deposit types correspond to respective protocols governing theprocedure by which the funds network converts the applicable negotiableinstrument to funds. In the presently described embodiments, the payeemay select via the ATM/kiosk/mobile device interface (at 806) one of thefollowing deposit types: immediate deposit, delayed funding, orpre-approval deposit (mobile telephone only, in some embodiments), butin other embodiments the interface may effect its own rules governingdeposit type. For instance, where the card manager controls the customerinterface, the card manager may require, and so correspondingly set inthe interface, the deposit type for each transaction originating from amobile telephone to pre-approval. The distinction among the deposittypes, in the presently described embodiments, is primarily thecondition that triggers each protocol to convert the negotiableinstrument to funds. For immediate funded deposits, the triggeringcondition is approval of the instrument by the run rules, and possiblythe risk center, or a third party check guarantor. For delayed fundingdeposits, the triggering condition is the passage of a predeterminedperiod of time sufficient to allow a check to clear under normal(non-hold) circumstances. For pre-approval deposits, the triggeringcondition is the same approval, plus a request, following the requestfor approval, to convert the instrument to funds. The different deposittypes carry different fees, and each type is discussed below.

Under an “immediate deposit” procedure, the funds network loads thecheck proceeds to a designated re-loadable card at the time the check ispresented for conversion to funds (assuming the check is approved forconversion to funds, as discussed herein), without waiting for the checkto clear the maker's bank. As such, the funds are immediately availableon the re-loadable card for the payee's use and can be immediatelydebited against the payee's reloadable card.

Under the “delayed funding” procedure, the check proceeds will not beavailable (and are on “hold”) until a specific time period aftersubmitting the check for conversion to funds. This delay allows time forthe check to clear the maker's bank so that the funds network receivesthe check proceeds from the maker's bank prior to making the fundsavailable to the customer. The delay or hold times may be, e.g., two toseven business days, or any time period desirable by the entitycontrolling the system, although preferably related to the check'sexpected settlement time.

Pre-approval check deposit means that when the payee submits an image ofthe check from a remote device, and in some embodiments only a mobiletelephone, the funds network may approve the check for conversion tofunds but does not make the funds available to the payee until the payeephysically presents himself at a check cashing location, if obtainingcurrency, or remotely requests a load to a card. Where the payeedeposits a check from a mobile telephone, the payee's remote device(i.e. the telephone) is unable to retain the paper check or providecurrency to the payee. The pre-approval deposit therefore allows a payeeto determine the check is approved for conversion to funds beforetraveling to a brick and mortar location to obtain currency and conveypossession of the paper check. Since currency can be immediatelyprovided from a kiosk or ATM, and since the ATM or kiosks can securepossession of the paper check (i.e. by retaining the physical check atscanning), pre-approval may not be provided as an option on thosedevices, in some embodiments.

Moreover, the interface at 802 may provide the payee not only with theoption to select the deposit type, but also to select whether the entityat risk in the transaction (in the embodiments discussed herein, thefunds network, the card manager, or a third-party guarantor) will haverecourse against the payee in the event the check is returned after thefunds conversion. That is, the payee can choose to convert an instrumentto funds with recourse back to the payee, such that if the instrument isreturned, the at-risk entity has the right to collect at least theinstrument amount from the payee. Alternatively, the payee may select todeposit the instrument without recourse, so that the at-risk entity hasno recourse against the payee in the event the check returns. Therecourse/non-recourse choice applied to any of the deposit types,thereby doubling the available options. Recourse transactions carry alower fee than non-recourse transactions, and so this choice, applied toa deposit type, defines the base fee.

In any event, at 808, the mobile application that interfaces with thepayee, or the ATM or kiosk interface, receives the check image andconverts the check image to a viable image acceptable to the fundsnetwork. The interface then sends a copy of the converted check image tothe funds network server, along with the check's magnetic ink characterrecognition (MICR) data that the interface extracts from the front imageof the check using optical character recognition (OCR) software,courtesy amount recognition (CAR, also extracted via OCR software), aflag value indicating a possibly-fraudulent dollar amount if theinterface determines that the CAR does not match the check amountentered at 802, the re-loadable card number (in the case of an ATM orkiosk), the payee's funds network member number (in the case of a mobiletelephone), a geocode of a mobile telephone, a location of a kiosk orATM, the selected deposit type, and the like. As will be discussedbelow, the geocode relates to the geographical coordinates of the mobiletelephone through which the payee submits the negotiable instrument forconversion to funds at a predetermined time, such as when the payeedeposits the instrument.

At 810, the funds network server receives the check image, member numberand other data from the interface. Receipt of this check informationfrom the interface is considered a request, to the funds network, toapprove the check for conversion to funds. In the case of immediatefunding and delayed funding, it is also considered a request to convertthe check to funds. In the case of pre-approval deposit, the request toconvert to funds comes later, as described with respect to FIGS.12A-12B.

At 812, the funds network server, or in some embodiments the Check 21provider, runs an OCR process on the check image received from the cardmanager server to extract text from the check, such as the MICR data,the CAR data, maker information and the like, as confirmation of the OCRdata from step 808, and creates a substitute check (or image replacementdocument) under the Check 21 protocol for the funds network, so that thefunds network has possession of the check. The funds network examinesthe OCR data obtained at both steps 812 and 808, at 824, to determine ifthe check image has a sufficiently high quality or if the check is apossible fraudulent check, as discussed below.

At 816, the funds network server verifies the balance on the re-loadablecard, and obtains any load limits on the card, by querying the cardmanager server. Each re-loadable card has a balance, whether a zero ornon-zero dollar amount. For some cards, there is a maximum amount thatcan be loaded onto the card. Since the funds network server knows theamount the payee is attempting to load on the card (from 806), the fundsnetwork server can determine if the maximum loadable amount will beviolated for that card. For example, a re-loadable card may have amaximum loadable amount of $1500, and if the payee is attempting to load$500 on the re-loadable card with a balance of $1200, the card will onlybe re-loaded to $1500. Thus, at 814, the funds network checks todetermine that the deposited amount from the check does not exceed alimit or threshold amount preset for the re-loadable card. If the limitor threshold will not be exceeded, a flag value is set indicating thecard load is “OK”; otherwise, the funds network server may provide anotification to the payee that the limits of the card would be exceededand disallow (setting the card load flag value to “not OK”) the depositto continue on the re-loadable card. At 818, if the card load flag valueis “not OK,” the funds network server sets a decline code at 820 asresulting from a “card load issue” and provides the payee (via theInternet, wireless or other network communication with the remote devicewhich the payee presented the check) with the decline reason at 821;otherwise, method 800 proceeds to 824 for further processing.

At 824, the funds network automatically determines, via a computingdevice, whether the OCR of the MICR data is viable by comparing the MICRdata, which was obtained from an OCR by the funds network server (at812), with the MICR data obtained by an OCR from the customer interface(at 808). If the MICR data acquired in both instances is the same, thefunds network server determines that the MICR data is viable. If the twoMICR data instances do not match, the method proceeds to block 832, asdiscussed below.

At 826, the funds network server automatically determines if the checkis a known check type. For example, if the funds network has previouslyseen the same ABA and account number as in the MICR line data for thischeck, the check type will have been stored by the funds network in itsdatabase in association with the corresponding ABA and account number,and the funds network can therefore determine whether this is a knowncheck type from database 202. However, if the check type is not known,the funds network server sends the check image to the risk center at 832for manual examination, as discussed below.

At 828, the funds network server automatically determines if the payeeis a new payee, i.e. if this is the first transaction handled by thefunds network for this payee. If the payee is a new payee, and alsodepending on the check type and check amount, the funds network servermay transfer the check to be processed manually at 834 by the riskcenter. The criteria for determining risk associated with a new payeecan vary as desired and depending on experience. The particular riskcriteria are not, in and of themselves, part of the present invention.

At 830, the funds network server automatically reviews the check amountflag sent by the customer interface. If that flag indicates a potentialdiscrepancy between the CAR value from the OCR, and the check amountentered by the payee, the funds network server directs the check tomanual review, at 832.

Steps 824, 826, 828 and 830 comprise a sequence of automated checkverification steps performed by the funds network server. If any ofthese verification checks/tests fail, method 800 proceeds to block 832,where the funds network server sends the check image to a risk centerfor manual verification.

At 832, the risk center receives images of a check triggered by one ofthe automated check verification processes, and a human operator at therisk center views the check images on a computer screen to manuallydetermine factors needed to determine fees applicable to the loadtransaction and review for potential fraud.

That is, in order to automatically determine the system transactionsfees in the presently described embodiments, the acquired check imagesshould be readable, and the check should be of a known type applicableto the underlying fee schedule, and the payee should have sufficienttransaction history in the system that a normal risk profile applies,and the check amount entered by the payee should be the same as theamount on the check. If these conditions are true, then the systemproceeds to step 836, without human intervention, to determine the feeas discussed below. If any one of the conditions fails, however, thefunds network server forwards the check images to the risk center. If at824 the acquired image is not sufficiently readable (i.e. the MICR datadid not match, indicating the image from which the MICR data wasextracted may be unclear), the operator viewing the images visuallyacquires the check information (including the MICR data) and interacts,via a user interface, with the funds network server to manually inputthe needed check information. If at 826 the ABA/Account number for thischeck is not already recorded in the funds network database, the checktype is one the system does not yet recognize, and the operator viewingthe images determines which of the system's predetermined check types isapplicable to the check and, again, manually inputs this information. Ifat 828 the payee is a new payee, the risk center operator assigns a riskfactor to the check that is considered by the run rules (FIGS. 9A-9B).If at 830, the check's dollar amount indicates a possible amount issue,the risk center operator verifies and corrects if necessary.

If the image quality is so poor that the risk center operator cannotread the check information, the risk center operator (interactivelythrough the funds network server's user interface) so notifies the fundsnetwork server at 834. The funds network server sets a decline code at822 as resulting from an “images issue” and provides the customerinterface with the decline reason at 821. The customer interfacetranslates the decline code to a predetermined message and displays thatmessage to the payee. If, however, the check images are readable, or ifthe risk center referral resulted from one of the verification steps826, 828, or 830 (which are inherently correctable by the risk centeroperator), the funds network server, having received the informationneeded to establish the transaction fees, proceeds to step 836. In thisprocess, the risk center operator can set a flag associated with thecheck to assure the funds network will not approve the check forimmediate funding at step 906 (FIGS. 9A-9B).

The funds network server applies a predetermined algorithm to determinethe transaction fee on a given check load. As indicated above, in thepresently described embodiments, the fee varies according to the checktype, with predetermined fees being applicable to the predeterminedcheck types according to a look-up table maintained in the funds networkdatabase. The fees may also vary depending on the deposit type requestedby the payee. For instance, the fee may be higher for an immediatedeposit transaction than for a delayed funding or pre-approvaltransaction, and higher for a pre-approval deposit than for a delayedfunding deposit, due to the higher risk to the funds network associatedwith immediate deposit. Each fee associated with a respective check typeis comprised of two portions—one applicable to the funds network, andone applicable to the card manager. The card manager entity and thefunds network entity may reach agreement regarding the fee, and how thefee portions are to be calculated, and how the fee is to be applied tothe load amount (e.g. as a percentage applied to the total check amount,or as a flat fee that may depend in some manner on the check amount,varying with check type and/or deposit type, or some other algorithm),and the funds network can apply the result to each check conversiontransaction on a transaction-by-transaction basis. The particular feestructure can be determined as desired and is not, in and of itself,part of the present invention.

Because the fee is applied on a transaction-by-transaction basis, andbecause both the funds network and the card manager actively participatein each transaction, either party can choose to discount its portion ofthe transaction fee on a transaction-by-transaction basis, or otherbasis, as desired. As noted, the funds network server establishes thefee at 836 based on the predetermined algorithm but can reduce itsportion of the fee for a given transaction (or based on some othercriteria, for example to reduce fees over a given calendar time periodor for certain payees or for certain check types and/or deposit types)before passing the initial fee (indicating both the funds networkportion and the card manager portion) to the card manager server at 838.At 838, the interface (operating automatically or in response to thecard manager) can choose to modify the card manager's portion of the feeif the card manager so desires, for example based on a time period,payee identification, check type and/or deposit type.

At 840, the interface notifies the payee what the fee will be, andtherefore the amount that will be loaded onto the payee's re-loadablecard. For example, if the total check amount is $500, and the fee at 836is $10, but the program manager offers a $2 promotion at 838, theinterface notifies the payee at 840 that the check amount is $500, thatthe total net load will be $492, and that the applicable fee is $8.

Additionally, at 840, the interface presents the payee an option tochange the deposit type in order to incur a lower fee, or for any otherreason. If the payee opts to change the deposit type, the user interfacepresents the payee with the deposit type options. If the customerselects a different deposit type, method 800 may return to block 836,and the funds network determines the fee based upon the newly-selecteddeposit type. The funds network server then presents the new fee to thecard manager server 838, which presents the new fee and load amounts tothe payee for acceptance, at 840. Alternatively, if the customerinterface stores a fee table with the applicable fee data, the customerinterface can recalculate the fee at 840, or display both fees up frontfor the payee's choice.

At 842, the customer interface presents an option to the customerwhether the customer wants to continue with the deposit of the loadamount, and subject to the fees, indicated at 840, and the customerinterface presents the payee with a selectable option accordingly. Theselectable option may be a button, drop down list or the like thatallows the payee to provide an indication that the payee wishes eitherto proceed or not proceed with the deposit. The customer interfacereceives the payee's selection. If the payee does not want to continue,the remote device customer interface sets an acceptance flag in atransaction record to “NO,” at 846. Otherwise, if the payee indicatesaffirmation to continue, thereby agreeing to the fees and total netamount, the interface so notifies the card manager server at 844.

At 844, the interface sets the type of transaction (e.g., immediatefunding, delayed funding, or pre-approval) and sends this information,along with any applicable fee adjustment to the funds network at 902.

At 902, the funds network server receives the results of the fee queryto the payee, including whether the payee wishes to continue with thetransaction and deposit the net amount and any adjustment to the cardmanager fee portion. If the payee does not wish to continue, then at903, the funds network server changes a status of the transaction recordto “deleted,” which ends the transaction. Unless required for regulatorypurposes, the transaction record (which may be stored in random accessmemory) may be deleted.

If at 902 the payee has accepted the transaction, and if at 904, thedeposit type is delayed funding, method 800 continues to the proceduredescribed with respect to FIGS. 10A-10B; otherwise, method 800 continuesto 906.

At 906 and 908, the funds network executes an automated algorithmagainst the check data to determine if the risk of instantly approvingthe check is below a predetermined threshold. If the algorithmdetermines the risk is below the threshold, processing continues at 916.Otherwise, the funds network server may determine that the risk is abovethe preset threshold and proceeds to steps 910-914. The funds networkserver provides the corresponding check images and associated checkinformation for eventual processing by the risk center (914), at which arisk center operator manually evaluates the check and the risk (asdiscussed below). The particular steps, criteria and thresholdsapplicable to a determination that a submitted check should be convertedto funds can vary as desired, for example based on a knowledge base ofhistorical data that provides a statistical assessment of the likelihoodof check validity under certain identifiable conditions. Such steps,criteria and thresholds themselves may vary based on the particularconditions in a given transaction, for instance depending on the deposittype and/or the recourse option the payee selects. The particular stepsand criteria applied in rules at 906 can therefore vary according tocircumstances and the experience and risk assessment of the entityoperating the system and, therefore, do not, in and of themselves, formpart of the present invention.

The present discussion assumes the funds network applies the run rulesanalysis at 906, but it should be understood that this function may bereferred to a third party check guarantor, for example via an auctionprocess as described above with respect to steps 84-96 in FIGS. 3B and3C. In the event the guarantor function is taken by a different party,that party may agree to accept liability for the check amount if thecheck is returned. Following a referral to a third party for checkverification, and receipt of a response from the third party, the methodresumes at step 916.

If, at 908, the funds network server does not give instant approval tothe check conversion following application of the run rules at 906, thefunds network so notifies the risk center at 910 and changes the statusof the transaction record to be “pending” at 912. The risk centerestimates a wait time to reach a conclusion regarding check validation,and the funds network server may transmit this information to thecustomer interface to thereby notify the payee.

At 914, the funds network server sends the check image and correspondinginformation to the risk center, at which an operator visually evaluatesthe check image and reviews the information, applying a predeterminedprotocol of rules to thereby determine whether the check should beconverted to funds. As described above with respect to step 906, theparticular steps and criteria applied in the manual evaluation at 914can vary according to the experience and risk assessment of the entityoperating the system and, therefore, do not, in and of themselves, formpart of the present invention. If, after application of thepredetermined protocol at 914, the risk center operator determines thecheck should not be converted to funds, the risk center operator sonotifies the funds network server via a user interface at 916, and thefunds network server changes the transaction record status to “Decline”at 918. Otherwise, if the risk center operator determines at 914 thatthe check should be converted to funds, and so notifies the fundsnetwork server at 916, the funds network server determines whether thedeposit type for this transaction is “pre-approval,” at 920.

As discussed above, the pre-approval deposit type allows the payee tosubmit the check for conversion to funds but wait to receive currencyuntil the payee presents the check to a card manager operator or fundsnetwork operator in person, or to later request a card load. If thepayee has selected the pre-approval deposit option, the funds networknotes this at 922, and the transaction moves to an inactive status, viastep 936, until the payee re-engages the transaction, as discussed belowwith regard to FIGS. 12A-12B.

If, at 920, the check deposit type is not pre-approval, and consideringthat the check deposit is also not delayed funding (see step 904), thenthe check deposit type is immediate deposit. Accordingly, at 924, thefunds network deposits the check image, via the Check 21 procedure, inthe reloadable card issuer's bank account at 924 and at 926 notifies thecard manager server of the total check amount and the applicable fees.The deposit and load procedure is described below with respect to FIG.13. The card manager server applies the load amount, less the fees, tothe payee's card, and sends confirmation to the funds network serverthat the card has been successfully loaded, at 928. If, at 928, thefunds network server receives confirmation that the card was loadedsuccessfully, the funds network server sets a print flag to “on,”indicating to the funds network server that the transaction successfullycompleted and sets a status code to “Approve” at 934. If, however, thecard manager reports that the card did not successfully load at 928, thefunds network server sets a card load error decline code in thetransaction record at 930 and 918.

At this point, the transaction status is “Decline” at 918, or “Approve”at 934, or “Pre-Approval” at 922, and the funds network servercommunicates the relevant status to the customer interface at 936. Themethod of the communication between the interface and the funds networkcan be either a push or a pull. If, at 936, the status is approved, i.e.the payee's card has been loaded by the load amount (less fees), thecustomer interface so notifies the payee via the remote device, andcommunicates a confirmation back to the funds network server, at 946,that the notification has been displayed. This ends the transaction.

If, at 936, the status is “pre-approval,” the customer interface sonotifies the payee at 938 and the card manager at 946. The transactionis then dormant until the system receives a request from the payee toconvert the pre-approved instrument to funds, as indicated at steps1204-1208 in FIGS. 12A-12B, through which the payee transfers possessionof the paper instrument to the card manager. The interface may alsoprovide the payee an option to locate a brick-and-mortar card managerfacility, or an ATM or kiosk affiliated with the card manager, asdescribed with respect to FIG. 11.

If, at 936, the status is declined, i.e. the check has not beenconverted to funds and the reloadable card not loaded, then the customerinterface checks at 940 whether delayed funding is still an option forthis transaction. Following the analysis steps 906 and 914, the fundsnetwork server records in the transaction record the basis for a checkdecline, and the funds network server passes this information to thecustomer interface at 936. By agreement, the funds network entity andthe card manager entity determine which decline bases result in anabsolute refusal to convert a check to funds. If any such bases exist inthe transaction at hand at 940, the transaction is not eligible fordelayed funding, and the customer interface so notifies the payee viathe remote device at 942. The interface communicates a confirmation backto the funds network server, at 946, and the transaction ends. Theparticular criteria for determining when a refusal basis results in anabsolute refusal to convert a check to funds can vary according to theexperience and risk assessment of the entity operating the system and,therefore, do not, in and of themselves, form part of the presentinvention.

If, however, the basis for declining the load does not result in anabsolute refusal at 940, then the customer interface queries the payeevia the remote device, at 944, whether the payee would prefer to end thetransaction or proceed under delayed funding. Also at 944, the customerinterface accepts the payee's response and communicates that response tothe funds network server. If the payee declines delayed funding at 944,the customer interface notifies the payee at 942 of the underlying basiswhy the transaction was declined, and the interface communicates aconfirmation back to the funds network server, at 946, ending thetransaction. If, however, the payee accepts delayed funding at 944, thecustomer interface changes the transaction status in its database todelayed funding, at 946, and notifies the funds network server of thedeposit type status change, at 948.

FIGS. 10A-10B illustrate the processing of a delayed fundingtransaction. Whether the payee selected delayed funding initially (seestep 904), for instance in order to have a lower transaction fee, orafter a declined transaction (see step 948), the funds network serverchecks at 1002 whether the check has been previously declined for any ofthe reasons that would trigger absolute refusal. Of course, this willnot be the case if the delayed funding transaction results from aselection at step 944, but it is possible that a payee is submitting acheck after a previous refusal and selecting delayed funding at theoutset of the new transaction, thereby triggering a delayed fundingprocess at step 904. Because the funds network database stores thetransaction records for declined transactions following steps 908 and914, the funds network server can check the database against the check(MICR) number to determine if there are any previous transactionsagainst this check number and, if so, what were any bases for decliningthe previous transaction. If at 1002 there is a previous transaction forthe subject check that was declined for a reason causing an absoluterefusal to convert the check to funds, then the funds network sets thetransaction record to “decline” at 1006 and notifies the customerinterface, which displays a notice to the payee, at 1004.

If, at 1002, there does not exist a previous basis for absolute refusalto convert this check to funds, the funds network server at 1008communicates to the Check 21 processor that the check will be depositedimmediately, but the card will be loaded a number of days later. Thiscauses a change in how the transaction handles the deposit and initiatesa process by which the Check 21 processor monitors the check's returnstatus until the day of the card load, as described below.

At 1010, the Check 21 processor deposits the check in a card managerbank account, as indicated at 1014 (via the Check 21 process) andestablishes or updates a table for delayed deposit timing at 1012. Inthis table, the Check 21 processor sets a date a predetermined time intothe future to allow the check to clear the settlement process. The delayperiod is set to a default value, e.g. five business days, sufficient toallow a check to clear under normal (non-hold) circumstances. Regardlessof the delay period's length, the Check 21 processor stores the delay inthe database table in association with the check.

On a daily or other periodic or desired basis, at 1017, the Check 21processor checks the table for any dates equal to the present date. Ifthe present date is earlier than a date in the table for a giventransaction record, the transaction remains dormant.

If, at 1017, the Check 21 processor identifies a date in the table thatis equal to the present date, the time has arrived to assess whether thecheck associated with the date in the table should be converted tofunds, and the Check 21 processor confirms at 1026 if the correspondingcheck has been returned. As noted above, the Check 21 processordeposited the check with the card manager's non-guaranteed account atstep 1010, thereby triggering the check's submission into the settlementprocess. If the check is returned from the maker's bank for insufficientfunds or other reason, the card manager's bank notifies the Check 21processor, at 1016, which notifies the funds network server, which inturn records this information in funds network database 202 (FIG. 4) inassociation with the check number at 1022. The Check 21 processor alsoupdates its table accordingly. The Check 21 processor or the fundsnetwork server notifies the card manager server of the return, and marksa record in the funds network database indicating this check is never tobe converted to funds, at 1024. At 1025, the card manager entitynotifies the payee of the returned check through means upon which thecard manager and the payee have agreed, such as hard copy mail,telephone call, or electronic communication. The card issuing bankdebits delayed funding account 1014 by the amount of the returned check,at 1018.

Accordingly, upon the check's delay period expiration, the Check 21processor reviews the database table at 1026 to determine whether areturn has occurred for this check. If so, the Check 21 processor setsthe status of the check's transaction record to “Returned” at 1030. Ifthe check has not been returned at 1026, the Check 21 processor sets thecheck's transaction record status to “Cleared” at 1028. The Check 21processor passes these flags to the funds network processor, whichdetermines the check's status, at 1032. If the check has cleared, thefunds network server updates its database record at 1040 and notifiesthe card manager, which then loads the check amount onto the payee'sreloadable card, less fees due to the funds network entity and the cardmanager entity, at 1038.

As noted above, the separation of the funds network and the Check 21processor as distinct entities is for purposes of convenience in thepresently described embodiments. It should be understood, however, thatthe Check 21 processor and the funds network could be the same entity.

FIG. 11 illustrates an initial step in a method by which a payee locatesa brick-and-mortar, ATM, or kiosk location through which the cardmanager can be accessed, to complete processing of a pre-approved check.As previously discussed, the payee can pre-approve a check through theremote device application. In that event, the funds network suspendsaction on the transaction, at 922 (FIGS. 9A-9B), until receivinginstructions from the payee to resume.

If the payee then wishes to complete the process of converting the checkto funds, the payee can access a user interface on a mobile telephonethrough which the payee can request assistance finding a location towhich to bring the check. Through the interface, the payee firstrequests a physical location at which to present the check, at 1102. Theinterface prompts the payee whether the payee wants to search forlocations near the payee's current location, or whether the payeeprefers to search by city/state/zip, at 1104.

If at 1104, the payee wishes to find the card manager location that isnearest to the payee's current location, the payee so indicates via themobile telephone application. The mobile telephone sends a signalincluding the telephone's present geocode location, using a GPS routinein the mobile telephone. As previously mentioned, the geocodecorresponds to and identifies the telephone's geographical coordinates.The interface receives and processes the telephone's current geocodereceived from the telephone's GPS module and compares the geocode withthe locations provided by the card manager that have a geocode closestto the customer's geocode, within a radius the payee specifies via theinterface (e.g., 1 mile) At 1106, the customer interface then retrievesall locations (from locations provided by the card manager within thespecified radius of the payee's geocode and displays these locations tothe customer via the interface for selection. The payee then selects adesired location and proceeds to that location.

If the customer wishes to perform a city/state/zip code search for alocation at 1104, the interface presents to the payee a search screenthat includes a portion that solicits various information from thepayee, such as the zip code or the city and state where the payee wishesto search for card manager locations. The payee then enters either thezip code or a city and state, at 1108. At 1109, the customer interfacefinds all locations that are within a predetermined or selected range ofthe center of the specified city/state or zip code. The interface thendisplays these locations to the payee using the screen of the payee'smobile telephone.

The customer interface allows the customer to select a location at whichto complete processing of the check, such as to present the check andreceive funds via reloadable card deposit or currency.

Having obtained pre-approval of a check (FIGS. 9A-9B), the payee willdecide at a later time to convert the check funds. In so doing, andreferring to FIG. 12A, the payee determines at 1202, whether to presentthe check in person to a card manager operator at a “brick-and-mortar”location in exchange for currency or to load the check proceeds to are-loadable card via a kiosk or ATM capable of accepting and securingpossession of the paper check. If the former, the payee finds abrick-and-mortar location (FIG. 11) controlled by the card managerentity, travels to that location, and presents the physical check to acard manager operator. The payee requests to convert the check to fundsand will transfer possession of the paper check to the operator. Theoperator obtains the payee's identification by any suitable means, forexample, by a question/answer sequence or review of suitabledocumentation. Upon confirming the payee's identification to theoperator's satisfaction or a predefined protocol, the operator scans thefront and back of the check using a scanner connected to the cardmanager computer system, so that the card manager server receives thecheck image. Through a user interface at 1206, the operator alsoprovides to the funds network server the check information, at 1208.That is, the operator, through the user interface and the network,forwards to the funds network the payee's request to convert the checkto funds. The funds network matches the check information to previouslyapproved, but not yet completed, transactions.

If the payee wishes to trigger conversion of a pre-approved check tofunds using an ATM or kiosk, the payee swipes the payee's re-loadablecard at a magnetic card reader associated with the ATM or kiosk (e.g.where the ATM interacts with the card manager server based on agreementbetween the card manager and the ATM owner). This allows the ATM orkiosk to acquire the reloadable card number and customer identity fromthe card's magnetic stripe, which triggers the device user interface toquery the payee for the payee's PIN. If the payee successfully entersthe PIN associated with the card number, the interface prompts the payeeto scan the check and enter the check amount. The ATM or kiosk, at 1206,transmits the check image, card account number and check amount to thefunds network server at 1208. This constitutes a request to convert tofunds a pre-approved check.

As described above with regard to FIGS. 9A-9B, when the funds networkapproves a check for which pre-approval is selected, the funds networksets the status of the transaction record associated with the check to“pre-approved.” The collective group of transaction records set to“pre-approved” status may, therefore, be considered a queue, and at1208, the funds network server queries this queue to determine if atransaction record matches the data in the request from the customerinterface. Accordingly, at 1210, the funds network server searches thequeue to determine if any transaction record has the same check MICRnumber as requested by the customer interface. If not, the funds networksets a predetermined flag in a response message to the customerinterface to indicate that no match was found to the query in the fundsnetwork database, at 1212.

If the check MICR data matches a transaction record in the fundsdatabase at 1210, the funds network server compares the check amountprovided in the customer interface request with the check amount storedin the matched transaction record. If these amounts do not match at1214, the funds network server sets a flag in the response message toindicate the dollar amount mismatch, at 1216.

If the dollar amounts match at 1214, the funds network server determinesat 1218 whether the customer interface request originates from abrick-and-mortar location or a remote device. This information isincluded in the request from step 1206, in that the originating deviceknows the request's origin and therefore includes suitable information.If, at 1218, the funds network server detects that the payee is presentat a brick-and-mortar location in originating the request, the fundsnetwork server changes the status of the applicable transaction recordto “approved” at 1220, and sets a flag in the card manager response to“approve,” at 1222. The funds network server then determines, at 1226,whether a third party Check 21 provider is affiliated with the cardmanager entity and authorized to deposit the checks with the cardmanager's bank. If so, the funds network deposits the check, via theCheck 21 processor, with the issuing bank, at 1230. Fees are deductedand provided to the funds network and the card manager as discussedbelow with regard to FIG. 13.

If, at 1218, the funds network server determines that the request fromthe customer interface is not from a brick-and-mortar location, thefunds network determines whether the card number included with therequest from the ATM or kiosk is associated with an account identifiedin the funds network database, at 1224. In another embodiment, this stepmay be omitted. If so, then, at 1228, the funds network server transmitsa message to the card manager server to load the check amount on to thepayee's card, as identified by the card number in the request. The cardmanager deducts fees as discussed below with regard to FIG. 13. Thefunds network server sets a flag in the card manager response toindicate a card load, at 1227, and the Check 21 processor deposits thecheck image at the issuing bank.

If the card number included in the request is not associated with anaccount at 1224, the funds network server sets a flag in the customerinterface request to indicate the problem, at 1225.

When the funds network server sends the response to the customerinterface, the customer interface reacts to the flag settings, asindicated at steps 1232-1250. If the response indicates, at 1232, thatno match was found for the MICR number at 1212, the customer interfaceprovides a notice to the payee, via the device interface if by ATM orkiosk, or by communication from the human operator if bybrick-and-mortar location, that the check number could not be found andthat the payee should resubmit the request, at 1234. If, at 1236, thecustomer interface determines from the response that the dollar amountsdid not match at 1214, the customer interface notifies the payee of thisproblem at 1238, and again prompts the payee to resubmit the request.If, at 1240, the customer interface determines that the funds networkserver approved the conversion to funds at a brick-and-mortar location,the computer system utilized by the requesting operator informs theoperator to pay the funds, at 1242, who provides currency to the payee,at 1244. If the customer interface server determines, at 1246, that arequest from a remote device did not include a valid card number at1224, the customer interface notifies the payee, at 1248, that thepre-approved check request is not associated with a card linked to anaccount. If, at 1250, the customer interface determines from the fundsnetwork server response that the pre-approved check proceeds were loadedon to a card at 1224 and 1228, the computer system utilized by therequesting operator, at 1252, notifies the payee of the card load, at1254.

FIGS. 13-14 illustrate settlement of deposit transactions following frompre-approval checks as in FIGS. 12A-12B or from immediately depositedcheck as in FIGS. 9A-9B. Referring first to FIG. 13, reference “E” is acontinuation of blocks 1224/1228 of FIG. 12B or step 926 of FIG. 9B orblock 1038 of FIG. 10B, and reference “D” results from either block 1224or 1226 of FIG. 12B or step 924 of FIG. 9B.

FIG. 13 illustrates an exemplary transaction, in which the check depositis $200 and the fees $5. The card manager distributes $3 of the $5 feeto the funds network, and the card manager thus keeps $2 of the $5charged fee. Other dollar amounts are certainly possible, and theseexemplary amounts are used solely for ease of illustration.

Reference “E” in FIG. 13 illustrates method 1300 proceeds to 1302, wherethe issuing bank credits the payee's card account for the dollar amountof the check ($200) and debits the payee's card account for the checkload fee ($5), as is discussed below. Therefore, the total net amountthat is deposited in the actual card account is $195.

At 1306, the funds network server sends data describing the full amountof the check, and fee amount, to the card manager's issuing bank, inassociation with the re-loadable card identification number. The cardidentification number associates the check amount and fee charged withthe specific re-loadable card.

At 1307, the card manager sends data describing the check transactionamount and the corresponding fee amount to the issuing bank (i.e. thebank that issues the card), in association with the card identifiernumber. This data should be the same as at 1306, which the issuing bankconfirms at 1308.

Reference “D” flows from the remote device portion of the flow in FIG.12B or step 924 in FIG. 9B, to 1315, in FIG. 13, where the Check 21processor deposits the check image at the card manager's issuing bankover an electronic network. The check image will be in the form of animage cash letter in the X9 file format, as required under Check 21procedures. Upon initiation of settlement, the funds network adds a datarecord to the transaction table at database 202, recording the payeeidentity, maker identity, check number, check type, check amount,acquirer identity, date, fees, and card manager identity.

At 1316, the card manager's issuing bank receives the image cash letterfile from the Check 21 processor and then forwards the image cash letterfile to the Federal Reserve under Check 21 rules. At this point, at1318, the issuing bank deposits the Check 21 value ($200) in a masterbank account 1320. Thus, the issuing bank credits $200 in the masterbank account.

At 1322, the issuing bank transfers the deposited money ($200) from themaster bank account to the card manager's operating account 1324. Assuch, the master bank account has been credited the check amount andthen debited the same amount, so the total net amount left in the masterbank account is zero dollars.

At 1312, the issuing bank transfers the check amount from the cardmanager's operating account to the card funding account 1314. Theissuing bank also debits the fee charged from the card funding accountand credits this amount to the card manager's proceeds account 1313. Forexample, the issuing bank debits the $200 check amount from the cardmanager's operating account and credits this amount to the card fundingaccount. At the same time, the issuing bank debits the $5 fee from thecard funding account to the card manager's proceeds account. As such, atotal net amount of $195 becomes the balance on the card fundingaccount. The card funding account is the account to which fundsavailable on the re-loadable cards must balance. Thus, funds in the cardaccount are equal to the card load amount. The card manager uses thecard manager's operating account for transferring check balances to cardfunding accounts. Thus the card manager uses the card manager'soperating account as a temporary transfer means. The card managerproceeds account may be linked with the card manager's vendor account sothat any fees owed to vendors are routed from the card manager'sproceeds account through the card manager's vendor account 1328(discussed below).

If the transaction is a delayed funding type, then once the card manageris informed to load the check amount at 1038 (FIG. 10B), the cardmanager transfers the check amount from the delayed funding account(1014, FIG. 10A) to the card funding account 1314, so that thetransaction files match at 1308.

At 1325, the funds network server sends the transaction file, with checkamounts and funds network fees, on a by transaction basis, to the cardmanager. This provides the card manager with the amounts that the cardmanager owes the funds network. The card manager uses the transactionfile to verify that the ACH or electronic depositing has occurred at1330.

At 1327, the third party Check 21 provider initiates an ACH orelectronic transfer of funds from the card manager's vender account 1328to the funds network's operating account 1326. In the ongoing example,the funds network is entitled to $3 of the $5 fee charged, and so thethird party transfers $3 from the card manager to the funds network. Atthis point, the payee has $195 in his card funding account, the fundsnetwork has $3, and the card manager has $2.

FIG. 14 illustrates a flow diagram view of a method for processing tworeturned checks—one check being returned for insufficient funds (NSF)and another being returned for fraud in the amounts of $50 and $175,respectively.

At 1402, the Federal Reserve returns the check along with the reason forreturn. The Federal Reserve sends a message to the issuing bank, whichinforms the Check 21 provider, at 1404. Additionally, the FederalReserve debits the issuing bank for such returned item, such as the $225in the present example. The issuing bank then charges the master bankaccount 1410 the debits from the Federal Reserve. Thus, the issuing bankcharges the master bank account $225.

At block 1406, the third party Check 12 provider provides the details ofthe return back to the funds network. This may be done by an electronicmessage that is then stored in a database at the funds network and isflagged for processing.

At 1408, if the check can be re-deposited, as is the case of the $50check in the example, the Check 21 processor includes a redeposit of theitem in the day's X9 file. If the check cannot be redeposited, the fundsnetwork operating account is instead debited by the Check 21 processorto the issuing bank for the full amount of the check, in this example$175.

Accordingly, in these embodiments, as in the embodiments discussed abovewith respect to FIGS. 3F and 3G, the funds network bears the risk of areturned check. It should be understood, however, that this risk can beallocated among the parties as desired. For instance, as discussedabove, the payee can select to submit a check for conversion to fundswith a right of recourse, so that if the check returns, the at-riskparty may pursue the payee for reimbursement. Alternatively, asindicated at 121 in FIG. 3E, the funds network may have contractuallyacquired a right of recourse against a third-party check guarantor wherethe system relies on such parties. Moreover, the funds network maycontract with the card manager to allocate a recourse right. This rightmay apply to all transactions or certain transactions, as agreed by theparties. For example, the funds network may agree to take the risk forimmediate and pre-approval deposits, but the card manager take the riskon delayed funding transactions. Where a party other than the fundsnetwork has the risk, that party compensates the funds network for thefull amount of the returned check, less the funds network fees,following step 1408, or for the full amount of the check, at step 121.

At 1420, the funds network then updates the database to indicate thatthe customer's check was returned and the reasons for such return. Thisallows for the funds network to identify which customers are a higherrisk for processing checks so that future deposits may be more closelyscrutinized.

While the above description is set forth with respect to one or moreembodiments, it should be appreciated the principles of the presentinvention are equally applicable to other embodiments within the scopeof the present disclosure and claims. Such other modifications andvariations to the present invention may be practiced by those ofordinary skill in the art, without departing from the spirit and scopeof the present invention, one or more embodiments of which are moreparticularly set forth in the appended claims. In addition, it should beunderstood that aspects of the various embodiments described herein andotherwise may be interchanged both in whole or in part. Additionalaspects may be understood from U.S. patent application Ser. No.13/767,624, entitled “Funds Network and Method”, filed Feb. 14, 2013,which is hereby incorporated by reference in its entirety. Furthermore,those of ordinary skill in the art will appreciate that the foregoingdescription is by way of example only and is not intended to belimitative of the invention so further described in such appendedclaims.

What is claimed:
 1. A method for activating functionality on a mobilesoftware application installed on a mobile device of a user to allow theuser to at least one of submit or transfer funds through a funds networkthat is not providing the mobile software application, the methodcomprising: receiving, by a computing system of the funds network andover a communication network, a name of the user and a memberidentification for the user; querying, by the computing system, aplurality of member identifications based on the member identificationfor the user to generate a query result, wherein each memberidentification of the plurality of member identifications is associatedwith an enrollment for using the funds network; identifying, by thecomputing system based on the query result, that the memberidentification for the user matches a corresponding memberidentification of the plurality of member identifications; responsive tothe member identification for the user matching the corresponding memberidentification, determining, by the computing system, that the name ofthe user matches a name associated with the corresponding memberidentification; and responsive to determining that the name of the usermatches the name associated with the corresponding memberidentification: activating, by the computing system, the correspondingmember identification for remote access; and returning, by the computingsystem over the communication network, an indication of acceptance tothe mobile software application, wherein the mobile software applicationnotifies the user of the indication of acceptance to allow the user toat least one of submit or transfer the funds through the funds network.2. The method of claim 1, wherein the corresponding memberidentification is associated with an electronic wallet from which thefunds can be allocated into a plurality of monetary repositories, andthe method further comprises: receiving, by the computing system via themobile software application over the communication network, a request toconvert a negotiable instrument to proceeds and an image of thenegotiable instrument; verifying, by the computing system, a validity ofthe negotiable instrument based on the image of the negotiableinstrument; and responsive to verifying the validity of the negotiableinstrument, directing the proceeds from the negotiable instrument to anelectronic wallet account associated with the electronic wallet.
 3. Themethod of claim 2 further comprising automatically allocating, by thecomputing system, at least a portion of the proceeds from the electronicwallet account to one of the plurality of monetary repositories based onthe user specifying the one of the plurality of monetary repositories.4. The method of claim 2 further comprising automatically allocating, bythe computing system, at least a portion of the proceeds from theelectronic wallet account to at least two of the plurality of monetaryrepositories.
 5. The method of claim 1, wherein the corresponding memberidentification is associated with an electronic wallet and a prepaidcard, and the method further comprises: receiving, by the computingsystem via the mobile software application over the communicationnetwork, a request to direct a first portion of proceeds to theelectronic wallet and a second portion of the proceeds to the prepaidcard, wherein the request comprises the corresponding memberidentification; identifying, by the computing system and based on thecorresponding member identification, the electronic wallet and theprepaid card; and responsive to identifying the electronic wallet andthe prepaid card, directing, by the computing system, the first portionof the proceeds to an electronic wallet account associated with theelectronic wallet and the second portion of the proceeds to a prepaidcard account associated with the prepaid card.
 6. The method of claim 5,wherein directing the second portion of the proceeds to the prepaid cardaccount comprises conducting an electronic funds transfer of the secondportion of the funds to a prepaid card provider computing system thatapplies the second portion of the funds to the prepaid card account. 7.The method of claim 5, wherein the electronic wallet account ismaintained by the funds network and the prepaid card account ismaintained by a prepaid card provider that is separate from the fundsnetwork and is associated with the mobile software application.
 8. Asystem providing a funds network used in converting payments to fundscomprising: a non-transitory computer-readable medium storinginstructions; and a processing device communicatively coupled to thenon-transitory computer-readable medium, wherein, the processing deviceis configured to execute the instructions and thereby perform operationscomprising: receiving customer information for a user, wherein thecustomer information comprises personal information of the user and acard number issued by a debit card manager for a reloadable debit card;responsive to receiving the customer information for the user:generating a member identification for the user; and associating thecustomer information with the member identification; receiving a requestfrom the user to convert a payment to funds, wherein the requestcomprises at least a portion of the personal information; and responsiveto receiving the request: identifying the member identification for theuser based on the portion of the personal information; identifying thecard number for the reloadable debit card based on the memberidentification; converting the payment to the funds via the fundsnetwork; and directing the funds to a debit card account associated withthe reloadable debit card based on the card number via an electronicfunds transfer to a computing system of the debit card manager.
 9. Thesystem of claim 8, wherein the request is received via a mobile softwareapplication residing on a mobile device of the user.
 10. The system ofclaim 8, wherein the member identification is associated with anelectronic wallet provided through the funds network.
 11. The system ofclaim 10, wherein the operations further comprise: receiving a secondrequest from the user to convert a second payment to second funds,wherein the second request comprises at least a portion of the personalinformation and indicates to direct a first portion of the second fundsto the reloadable debit card and a second portion of the second funds tothe electronic wallet; and responsive to receiving the second request:identifying the member identification for the user based on the portionof the personal information; identifying the card number for thereloadable debit card based on the member identification; identifyingthe electronic wallet based on the member identification; converting thesecond payment to the second funds via the funds network; directing thefirst portion of the second funds to the debit card account associatedwith the reloadable debit card based on the card number via a secondelectronic funds transfer to the computing system of the debit cardmanager; and directing the second portion of the second funds to anelectronic wallet account associated with the electronic wallet.
 12. Thesystem of claim 11, wherein the debit card account is maintained by thedebit card manager and the electronic wallet account is maintained bythe funds network.
 13. The system of claim 10, wherein the electronicwallet is associated with a plurality of monetary repositories, and theoperations further comprise: receiving a second request from the user toconvert a second payment to second funds, wherein the second requestcomprises at least a portion of the personal information and indicatesto direct the second payment to the electronic wallet; responsive toreceiving the second request: identifying the member identification forthe user based on the portion of the personal information; identifyingthe electronic wallet based on the member identification; converting thesecond payment to the second funds via the funds network; and directingthe second funds to an electronic wallet account associated with theelectronic wallet; and automatically allocating at least a portion ofthe proceeds from the electronic wallet account to at least two of theplurality of monetary repositories.
 14. The system of claim 10, whereinthe operations further comprise: receiving a second request to convert asecond payment to second funds, wherein the second request comprises atleast a portion of the personal information; and responsive to receivingthe second request: identifying the member identification for the userbased on the portion of the personal information; identifying theelectronic wallet based on the member identification; converting thesecond payment to the second funds via the funds network; and directingthe second funds to an electronic wallet account associated with theelectronic wallet.
 15. A non-transitory computer-readable medium havingprogram code that is stored thereon, the program code executable by oneor more processing devices within a funds network for performingoperations comprising: generating a member identification for a user;and associating the member identification with an electronic walletprovided by the funds network; associating, based on input provided bythe user, the electronic wallet with a plurality of monetaryrepositories; receiving a request from the user to transfer a firstportion of funds from the electronic wallet to a first monetaryrepository of the plurality of monetary repositories and a secondportion of the funds from the electronic wallet to a second monetaryrepository of the plurality of monetary repositories, wherein therequest comprises the member identification; and responsive to receivingthe request: identifying the electronic wallet based on the memberidentification; directing the first portion of the funds from anelectronic wallet account associated with the electronic wallet to thefirst monetary repository via a first electronic funds transfer to afirst computing system of a first entity associated with the firstmonetary repository; and directing the second portion of the funds fromthe electronic wallet account to the second monetary repository via asecond electronic funds transfer to a second computing system of asecond entity associated with the second monetary repository.
 16. Thenon-transitory computer-readable medium of claim 15, wherein the requestis received via a mobile software application residing on a mobiledevice of the user.
 17. The non-transitory computer-readable medium ofclaim 16, wherein the operations further comprise activatingfunctionality on the mobile software application to allow the user to atleast one of submit or transfer the funds through the funds network. 18.The non-transitory computer-readable medium of claim 15, wherein theoperations further comprise: receiving a second request from the user toconvert a payment to additional funds, wherein the second requestcomprises the member identification; and responsive to receiving thesecond request: identifying the electronic wallet based on the memberidentification; converting the payment to the additional funds via thefunds network; and directing the additional funds to the electronicwallet account associated with the electronic wallet.
 19. Thenon-transitory computer-readable medium of claim 15, wherein the memberidentification is associated with a prepaid card, and the operationsfurther comprise: receiving a second request from the user to transfer athird portion of the funds from the electronic wallet to the prepaidcard, wherein the request comprises the member identification; andresponsive to receiving the second request: identifying the electronicwallet based on the member identification; identifying the prepaid cardbased on the member identification; and directing the third portion ofthe funds from the electronic wallet account to a prepaid card accountassociated with the prepaid card via an electronic funds transfer to acomputing system of a prepaid card provider associated with the prepaidcard.
 20. The non-transitory computer-readable medium of claim 19,wherein the electronic wallet account is maintained by the funds networkand the prepaid card account is maintained by the prepaid card providerthat is separate from the funds network.